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OD REDAKCJI 


Niniejszy specjalny numer ALGORITMÓW stanowi 
zbiór referatów wygłoszonych na Sympozjum: "Meto¬ 
dy programowania i opisu systemów operacyjnych” 
w Warszawie w dniach 18-20 października 1973, zor¬ 
ganizowanym przez Zakład Teorii SystemówOperacyjnych 

Zespół Redakcyjny, pełniący rolę zarówno recen¬ 
zentów, jak i redaktorów tego numeru, postawił so¬ 
bie za cel przekazać do druku dostarczone przez 
referentów teksty w postaci możliwie jednolitej 
tematycznie i terminologicznie. Członkowie Zespo¬ 
łu zdalą sobie sprawę, że mimo poczynionych zmian 
i skreśleń, nie udało się w pełni osiągnąć celu* 
Powodów tego stanu rzeozy łatwo się domyślić, po 
pierwsze, tematem sympozjum była dziedzina, w któ¬ 
rej panuje jeszcze chaos pojęciowy, po drugie, sy¬ 
tuację pogarsza jeszcze brak odpowiedniej termino¬ 
logii polskiej, w której występują często terminy 
angielskie, jednakże różnie przez różnych autorów 
rozumiane i w różnych znaczeniach używane# Dlatego 
też Czytelnik znajdzie w tekście numeru odnośniki 
pochodzące od Zespołu Redakcyjnego, które, mamy 
nadzieję, będą pomoone w czytaniu. 

Wszystkie zmiany i skreślenia, o których mowa 
wyżej, są natury wyłącznie terminologicznej lub do- 
tyozą zakresu tematycznego Sympozjum. Zespół nie 
wprowadził żadnych zmian, ani nie skreślił zdań, 
wyrażających poglądy odmienne od poglądów członków 
Zespołu. Czytelnik może więo znaleźć w niniejszym 
wydawnictwie różne poglądy i sposoby potraktowania 
tych samyoh problemów, różne podejścia i sposoby 
rozumowania prowadzące do stworzenia systemu opera¬ 
cyjnego i jego dokumentacji# 

Zbiór materiałów otwiera referat wstępny 
W.M. Turskiego, stanowiący uzasadnienie traktowa¬ 
nia problemów konstruowania systemów operacyjnyoh 
jako problemów naukowych, pilnie wymagających upo¬ 
rządkowania zbioru pojęć tej dziedziny i stworze¬ 
nia odpowiednich metod, które umożliwią szybsze 
konstruowanie systemów operacyjnych, możliwie po¬ 
prawnie działających. 


Układ pozostałyoh materiałów Sympozjum tylko z 
grubsza pokrywa się z jego programem. Program był 
sporządzony z uwzględnieniem ram ozasowyoh poszoze- 
golnyoh sesji. Natomiast w druku staramy się zacho¬ 
wać jedność tematyczną poszczególnych ozęśoi, na 
jakie cały materiał został podzielony. 

W części dotyoząpej synchronizacji procesów Czy¬ 
telnik znajdzie referat przeglądowy T. Englerta, 
traktujący o sposobach zapisu synchronizaoji równo- 
legły oh procesów i o próbach wykazywania tego- że 
synchronizacja jest poprawna. Temu tematowi również 
jest poświęcony komunikat S. Chrobota, opisujący 
pewien minimalny zbiór operacji synchronizacyjnych, 
wystarczający do zaprogramowania dowolnie złożonych 
struktur procesów równoległych. 

Odrębną część materiałów stanowią prace A-C* Ro- 
wickiego dotycząoe sposobów wyliczenia, ile trzeba 
procesorów do zrealizowania równoległych procesów 
o zadanej strukturze oraz wyliczenia minimum czasu, 
w którym procesy te zostaną zrealizowane przy zada¬ 
nej liczbie procesorów. Pierwsza z nich jest wprowa¬ 
dzeniem do zagadnienia, potraktowanym przeglądowo, 
druga - komunikatem podającym sposób wyliczenia tych 
wielkości dla grafowych struktur procesów równole¬ 
gły oh. 

V/ części dotyczącej modelowania systemów cyfro¬ 
wy oh many referaty przeglądowe P. Bielkowicza i 
P. Perkowskiego oraz J. Marońskiego. Pierwszy z 
nich omawia metody modelowania i symulacji takioh 
systemów od strony pojęć i reguł przy tym stosowa¬ 
nych. Drugi zawiera również przegląd zrealizowanych 
i stosowanych systemów modelowania i symulacji za¬ 
równo programowych jak i sprzętowych. 

Następna część materiałów zawiera refei^aty trak- 
tująoe o problemach i metodach programowania oraz 
dokumentowania systemów operacyjnych. Pierwszy z 
nich H. i J. Mysiorów jest próbą zrealizowania tego, 
co się określa jako warstwową i modularną budowę 
systemów operacyjnych. Drugi, J. Olszewskiego, trak¬ 
tuje o możliwościaoh strukturalnego programowania 
systemów operacyjnych w językaoh tzw. wyższego po¬ 
ziomu. Następny referat J. Pieli i W. Skurzaka jest 
krótkim komunikatem o sposobie rozszerzenia możli- 
wośoi funkcjonalnych programu Egzekutor dla maszyny 
ODRA 1304. Komunikat Z. Kosowskiego i Z. Bytnerowi- 
oza dotyczy sposobu konstruowania zestawu programów 
manipulacyjnych jako część dużego systemu operacyj¬ 
nego. Ostatni z referatów tej części jest również 
krótkim komunikatem na temat dokumentacji systemów 
operaoyjnyoh potraktowanej niejako oddzielnie od 
samego programowania. 


Kolejną i ostatnią iuż ozęść materiałów stano¬ 
wią komunikaty o niektoryoh właśnie zrealizowanych 
lub nawet jeszoze realizowanyoh systemaoh operaoyj- 
uyoh i o sposobaoh ioh realizaoji. Całą tę ozęśó 
można potraktować jako zbiór ilustracji niektórych 
ogólryoh tez wypowiedzianych w referataoh przeglą¬ 
dowych i problemowyoh umieszozonyoh w poprzednich 
ozęśoiaoh materiałów. Zestawlająo ze sobą referaty 
ogólne i ten zbiór przykładów Czytelnik może prze¬ 
konać się, że w większośoi przypadków ilustrują one 
trudnośoi systematycznego i strukturalnego podejś- 
oia do problemu konstruowania systemów operacyj¬ 
nych. 
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ZAGAJENIE SYMPOZJUM 


Władysław M. TURSKI 

Instytut Maszyn Matematycznych 
Warszawa, ul. Krzywickiego 34 

Pracę złożono 10.1 .1974 


Wymieniono praktyczne powody, dla których należy 
prowadzić badania w zakresie systemów operacyj¬ 
nych. Należą do nich: konieczność budowy wielu 
systemów operacyjnych dla różnorodnych zastosowań 
systemów minikomputerów oraz dla niestandardowych 
zastosowań dużych maszyn. Podano kilka przykładów 
problemów naukowych występujących przy badaniach 
systemów operacyjnych, a mianowicie: współdziała¬ 
nie niezależnych procesów, styk pomiędzy sprzętem 
* jego oprogramowaniem, przejmowanie funkcji 
oprogramowania przez sprzęt, nowe problemy opty¬ 
malizacji. Wymieniono i pobieżnie przeanalizowano 
nierozwiązane problemy w dziedzinie systemów ope¬ 
racyjnych, takie jak: metody projektowania, po¬ 
prawność, optymalizacja, współdziałanie i styk 
pomiędzy sprzętem i oprogramowaniem oraz pomiędzy 
systemami operacyjnymi i translatorami. 

o 

Zanim przejdę do treści meiytorycznej mojego referatu, 
obciąłbym przywitać uczestników Sympozjum w imieniu Dyrekcji 
Instytutu Maszyn Matematycznych oraz w imieniu naszego macie¬ 
rzystego Zjednoczenia "MERA”, z radością witającego seminaria 
i sympozja naukowe organizowane z tak szeroką reprezentacją 
pracowników nauki i praktyków informatyki* Jest mi szczególnie 
Przyjemnie powitać uczestników sympozjum z zakresu teorii sys¬ 
temów operacyjnych, zwłaszcza, że jest to dziedzina, którą bo¬ 
dajże 7 lat temu nikt jeszcze się w Polsce nie zajmował, a te¬ 
raz znalazła się wystarczająca liczba referatów i komunikatów, 
ażeby zorganizować 2 sympozja w odstępie zaledwie dwutygodnio¬ 
wym (następne sympozjum organizuje Zakład Systemów Automatyza¬ 
cji Kompleksowej PAN w dniach od 5 do 10 listopada). 
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Władysław M. TURSKI 


W oiągu 5-dniowyoh obrad wysłuchamy kilkunastu referatów i 
komunikatów, które będą miały poważną treść teohniozną, tzn. 
będą zawierały informacje liczbowe, wzory, wykresy itp. Jest 
to oczywiśoie oznaką znacznego rozwoju tej dziedziny* zaczyna¬ 
ją się formować szkoły, teorie, W niedługim ozasie zaczniemy 
tworzyć systemy operacyjne i modele systemów operaoyjnyoh opar¬ 
te na śoisłych kanonach; system operacyjny to będzie piątka ozy 
szóstka, oozywiśoie uporządkowana, która będzie miała śoiśle 
określone własności i jeżeli systemy operacyjne w rzeczywistoś¬ 
ci własnośoi tych posiadać nie będą, to tym gorzej dla rzeczy¬ 
wistości. Systemem operacyjnym będzie nie to, co jest na maszy¬ 
nie, ale ta piątka, szóstka, czy ósemka, a może kiedyś dwunast¬ 
ka i trzynastka uporządkowana, jako że system operacyjny jest 
bardzo skomplikowanym układem. Jeszcze trochę, a dojdziemy w 
tej dziedzinie do wymaganych kryteriów "akademickości" dyscy¬ 
pliny. 

Skoro więc oczekuje nas spora porcja komunikatów i refera¬ 
tów technicznych, ścisłych, ja zajmę trochę czasu rozważaniami 
natury luźniejszej. Wydaje mi się, że czasami warto na jakąś 
dziedzinę ludzkich umiejętności, żeby nie powiedzieć wiedzy, 
popatrzeć nie tyle z perspektywy publikacji, z perspektywy bar¬ 
dzo rygorystycznego wzoru, czy z jeszcze bardziej rygorystycz¬ 
nego układu aksjomatów, i nawet nie z punktu widzenia konkret¬ 
nej realizacji, na konkretnej maszynie, w konkretnym ozasie, 
dla konkretnych użytkowników, ale z punktu widzenia badacza, 
który przecież podejmuje trud zajmowania się jakąś dyscypliną 
również i dlatego, że interesują go pytania: dlaczego, po co, 
gdzie w układzie rzeozy to, ozym się zajmuje jest umiejscowio¬ 
ne i jak się wiąże ze swym otoczeniem. Takimi rozważaniami 
chciałbym się z państwem teraz podzielić. 

Pierwszą sprawą będzie pytanie - dlaczego zagadnienia syste¬ 
mów operacyjnych są ważne? 

Patrząo na to co się dzieje w zakresie instalacji maszyn, 
widzi się te wielkie, bardzo drogie maszyny instalowane, dos¬ 
tarczane z gotowym systemem operacyjnym, lepszym czy gorszym, 
ale prawie zawsze zbyt wielkim, żeby działaniem jednostkowym 
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czy nawet d ział sin iem niewielkiej grupy można było zmienić, 
ulepszyć, zaadaptować taki system operacyjny. Innymi słowy, 
kiedy marny do czynienia z behemotami typu systemów operacyj¬ 
nych IBM, właściwie stajemy się bezradni, to już nie jest 
obiekt, który można zmieniać. To jest coś jak masa Ziemi. Nie 
poddaje się zmianom. To jest constant. Nawet biorąc pod uwagę 
to, że funkcją programów jest u nas w kraju głównie pewna adap¬ 
tacja, docieranie, dopasowywanie istniejących systemów opera¬ 
cyjnych do jednego, dwóch, może pięciu urządzeń, to koncepcyj¬ 
nie rzecz jest stała. 

Jednakże, równocześnie z pojawieniem się tych behemotów, ob¬ 
serwujemy inwazję, jeśli można tak powiedzieć, minikomputerów 
różnej proweniencji, które nie są z natury rzeczy przeznaczone 
do eksploatacji w sposób standardowy. A że mają one zadziwiają¬ 
cą zdolność do przejawiania się. w bardzo różnorodnych konfigu¬ 
racjach, jest chyba praktyczną potrzebą umieć robić systemy ope- 
racyjne dla systemów, w których minikomputery pojedynczo, albo 
w zespołach odgrywają rolę procesorów. Relatywna taniość tych 
maszyn powoduje, że modele ioh użytkowania będą bardzo różne. 

W przeciwieństwie do maszyn wielkich, w których model użytkowa¬ 
nia jest jeden, dwa, być może trzy i gdzie woboc tego są jeden, 
dwa czy trzy warianty systemu operacyjnego, używane faktycznie 
w wielu tysiącaoh egzemplarzy każdy; systemy operacyjne dla 
licznych konfiguracji i zastosowań przeróżnych systemików ozy 
systemów minikomputerowych będą miały zapewne dużo większą róż¬ 
norodność. A więc powstaje praktyczna potrzeba zdobycia umie¬ 
jętności robienia systemów operacyjnych. 

DrUga potrzeba praktyczna robienia systemów operacyjnych, 
występująca znacznie rzadziej, ale chyba bardziej atrakcyjna - 
to niestandardowe systemy z wykorzystaniem maszyn dużych. Licz¬ 
bowo jest ich chyba niewiele, tym niemniej będą występowały i 
będą zapewne wymagały unikalnych systemów operacyjnych dostoso¬ 
wanych do takich niestandardowych zastosowań. Przykładem nie¬ 
standardowych zastosowań jest chociażby system rezerwacji bile¬ 
tów, bo w końcu będzie w Polsce jeden system rezerwacji biletów 
kolejowych. Być może będzie drugi system rezerwacji biletów lot- 
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niczyoh, aczkolwiek na razie patrząc na rozkład lotów wewnętrz¬ 
nych linii PLL ,, Lotu ,, f wydaje się, że taki system można by zna¬ 
komicie zorganizować bez jakiegokolwiek komputera. Ponieważ 
systemów rezerwacji miejsc nie będzie dużo, więc również nie 
będzie zapewne standardowego systemu rezerwacji miejsc - będzie 
to tylko jeden system rezerwacji miejsc z własnym, unikalnym 
systemem operacyjnym. 

Trzecia kategoria praktycznych potrzeb konstruowania syste¬ 
mów operacyjnych wyniknie z wysoce niestandardowych konfigura¬ 
cji sprzętowych. Nie mam na myśli minikomputerów, bo w ich przy¬ 
padku zakładam, że normą jest fakt niestandardowości konfigura¬ 
cji, zwłaszcza w zastosowaniach w sterowaniu i w eksperymentach, 
ale również duże maszyny mogą występować w bardzo niestandardo¬ 
wych konfiguracjach, np. są to maszyny cyfrowe użyte w roli cen¬ 
tral telekomunikacyjnych, gdzie prooesor właściwie bardzo mało 
przetwarza, a bardzo dużo przełącza. Takie niestandardowe konfi¬ 
guracje i zastosowania będą wymagały unikalnych systemów opera¬ 
cyjnych, a więc wzbudzą konkretne potrzeby wykonawcze i postawią 
problem umiejętności efektywnego wykonywania systemów operacyj¬ 
nych. Jeśli jednak ma to być tak, to nie wystarcza uczyć się o 
systemaoh operacyjnych, żeby umieć robić systemy operacyjne 
trzeba pewnej praktyki. 

Drugim powodem dlaczego zagadnienia systemów operacyjnych są 
ważne, a może nawet ważniejszym są względy poznawcze. Najpierw 
ohoiałbym trochę zareklamować systemy operacyjne. Co prawda, 
w gronie uczestników tego sympozjum nie bardzo ma to sens, ale 
ohyba warto zdać sobie sprawę, że właśnie przy studiowaniu za¬ 
gadnień systemów operacyjnych po raz pierwszy zetknęliśmy się 
z rzeczywistymi, konkretnymi zagadnieniami, w który oh jednoczes- 
ność działania i problemy synchronizacji są sprawą podstawową. 
Dopóki nie weszliśmy w zagadnienia systemów operacyjnych, świa¬ 
domie lub nieświadomie (a nastąpiło to zapewne wcześniej nim 
powiedzieliśmy wyraźnie, że zaczęliśuy zajmować się systemami 
operacyjnymi), w badaniach naukowych można było stosować zasa¬ 
dę divide et impera. Co więcej, jest to klasycznym zaleceniem 
badawczym - "rozłóż problem na części składowe i studiuj każdą 
z nich oddzielnie". Nie chcę przez to powiedzieć, że systemów 
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operaoyjnyoh nie chcielibyśmy też tak badać - właśnie tak chcie¬ 
libyśmy je badać. Tyle tylko f że podziału tego nie można 
przeprowadzić tak łatwo i prosto jak w systemach, w których jed- 
noczesność działania i problemy współdziałania, synchronizacji, 
problemy interferencji pożyteoznej i interferenoji szkodliwej 
procesów współbieżnych nie występują. Otóż z taką ostrośoią pro¬ 
blemy te wystąpiły po raz pierwszy dopiero przy systemaoh opera- 
°yjnyoh. Oozywiśoie, wszystko to zaozyna się teraz przeradzać 
w osobną gałąź badań. Zawsze bowiem tak jest, że problem zrodzo- 

w warunkaoh kontaktu ze światem rzeczywistym, po pewnym cza¬ 
sie degeneruje się, ozy wyradza w przedmiot "czystych" zaintere¬ 
sowań naukowych, nie czerpiących już materiału z konfrontaoji 
2 rzeczywistością, bo mająoyoh dość materiału założonego i wyge¬ 
nerowanego przez sprawnie działająoy aparat rozbudowy aksjomatów 
i twierdzeń. 

Drugi, w moim przekonaniu równie atrakcyjny, aspekt poznaw- 
ozy systemów operacyjnych polega na tym, że właśnie poprzez sys¬ 
temy operaoyjne, przez ich studiowanie uzyskuje się właściwy po¬ 
ziom abstrakoji dla analizy architektury systemu licząoego. Ana¬ 
lizowanie, ozy zastanawianie się nad problemami architektury 
systemów lioząoyoh, przynajmniej mnie osobiśoie, najłatwiej pro¬ 
wadzić z punktu widzenia systemu operacyjnego. Właśnie przez sys¬ 
tem operacyjny najdogodniej widzę zarówno konfiguraoję, jak i 
arohitekturę. Na poziomie systemu operacyjnego jestem dostatecz¬ 
nie uwolniony od szozegółów technicznych, tzn. widzę je z odpo¬ 
wiedniej perspektywy, a jednooześnie dostrzegam wszystkie funk— 
oje sprzętowe, które są interesująoe z punktu widzenia eksploa¬ 
tacji (a nie konserwacji). 

Co więoej f właśnie badająo systemy operacyjna, i z ioh punk¬ 
tu widzenia arohitekturę systemów, doohodzi się do pewnyoh uwag 
odnośnie zmian w konstrukcjach sprzętowyoh. Niekiedy mówi się 
o tym, że jest to przejmowanie funkoji oprogramowania przez 
sprzęt. Oozywiśoie jest to tylko kwestia akcentów słownych, 
i wydaje mi się, że nie jbst to tylko przejmowanie funkoji opro¬ 
gramowania przez sprzęt, lecż także przejmowanie przez projek¬ 
tantów sprzętu wyników badań systemów operacyjnych. 
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Wymieniono praktyozne powody, dla których należy 
prowadzić badania w zakresie systemów operacyj¬ 
nych. Należą do niohl konieozność budowy wielu 
systemów operAoyjnyoh dla różnorodnych zastosowań 
systemów minikomputerów oraz dla niestandardowych 
zastosowań dużych maszyn. Podano kilka przykładów 
problemów naukowyoh występującyoh przy badaniach 
systemów operaoyjnyoh, a mianowicie: współdziała¬ 
nie nlezależnyoh procesów, styk pomiędzy sprzętem 
i jego oprogramowaniem, przejmowanie funkcji 
oprogramowania przez sprzęt, nowe problemy opty¬ 
malizacji. Wymieniono i pobieżnie przeanalizowano 
nierozwiązane problemy w dziedzinie oystemów ope- 
raoyjnych, takie Jaki metody projektowania, po¬ 
prawność, optymalizacja, współdziałanie i styk 
pomiędzy sprzętem i oprogramowaniem oraz pomiędzy 
systemami operaoyjnymi i translatorami. 


Zanim przejdę do treśoi merytoryoznoj mojego referatu, 
ohoiałbym przywitać uozestników Sympozjum w imieniu Dyrekoji 
Instytutu Maszyn Matematyczny oh oraz w imieniu naszego macie¬ 
rzystego Zjednoozenia "MERA", z radośoią witająoego seminaria 
i sympozja naukowe organizowane z tak szeroką reprezentaoją 
praoowników nauki i praktyków informatyki. Jest mi szozególnie 
przyjemnie powitać uozestników sympozjum z zakresu teorii sys¬ 
temów operaoyjnyoh, zwłaszoza, że jest to dziedzina, którą bo¬ 
dajże 7 lat temu nikt jeszoze się w Polsoe nie zajmował, a te¬ 
raz znalazła się wystarozająoa liozba referatów i komunikatów, 
ażeby zorganizować ?. sympozja w odstępie zaledwie dwutygodnio¬ 
wym (następne sympozjum organizuje Zakład Systemów Automatyza¬ 
cji Kompleksowej PAN w dniaoh od 5 do 10 listopada). 
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prao i sporo metod dowodzenia poprawności programów, oo od ra¬ 
zu powoduje, że trzeba określić "poprawność programu"• Ja mó¬ 
wię ostrożniej, chodzi mi o dowodzenie poprawności sądów orze¬ 
kanych o programach. Tutaj spodziewany się bardzo wiele po ba¬ 
daniach teoretyczny oh, jak zwykle przy sprawach, które nas sil¬ 
nie pasjonują, Ale droga ta okazuje się pełna cierni i powolna, 
bo nawet dla programu sortowania wewnętrznego dowód nie jest 
zbyt prosty. Zdaje się, że dla bardziej złożonych programów, 
żadryoh dowodów poprawności dotyohozas nie podano. A przecież, 
mimo że program sortowania nie jest problemem trywialnym, dale¬ 
ko mu do złożonośoi zagadnienia systemu operacyjnego. Może 
więo nie stawiać sobie zadania dowodzenia orzeczeń o systemach 
operacyjny oh, może zastanowić się nad metodami weryfikacji tyoh 
systemów, bo z tym też jest niedobrze. Systeny operacyjne spraw¬ 
dzamy na tak nieznacznej liozbie przypadków, że gdyby w pięoio- 
ozy sześcioletniej eksploatacji tyle tylko było pomyłek, ile 
sukcesów w ozasie testowania, to taki system byłby niezły. Oczy¬ 
wiście zagadnienie weiyfikaoji łączy się z problemem projektowa¬ 
nia systemów - dążenie do weiyfikowalnośoi systemu operacyjnego 
powinno być równie ważnym kryterium projektowym jak funkojonal- 
hs. niezawodność, innymi słowy być może dążenie do weiyfikówatl- 
nośoi nie jest najważniejszym kryterium projektowania systemu 
operacyjnego, ale powinno być jednym z najważniejszych. 

Trzecim problemem badawozym są metody adjustaoji systemów 
operaoyjnyoh. Może niezręoznie użyłem słowa "adjustacja", ale 
ohodzi mi tutaj o słowo ogólniejsze niż te trzy podproblemy, 
które ohoę wyliczyć, a więc: zagadnienie przystosowalnośoi, 
przez co rozumiem zmiany konstrukoji systemu operaoyjnego poz¬ 
walające dostosować go do potrzeb użytkownika, zagadnienie roz¬ 
szerzalności ożyli dostosowanie systemu operacyjnego do zmian 
konfiguraoji i zagadnienie przenośnośoi, tj. przenoszenie sys¬ 
temu operaoyjnego z konfiguraoji na konfigurację, przy istot¬ 
nych różnioaoh między nimi. O ile rozszerzalność dotyozy roz¬ 
szerzenia konfiguraoji w obrębie rodziny, czyli np. dodania 
pamięoi ozy urządzeń, to przenośność oznaoza przenoszenie sys¬ 
temu operaoyjnego z maszyny na inną maszynę. Należałoby mówić 
o ewentualnej przenośności, bo czy system operacyjny może być 
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przenośny, ozy powinien być przenośny, są to właśnie Zagadnie¬ 
nia badawoze, któryoh rozwiązań jeszoze nie znamy. Otóż metody 
adjustaoji, obejmujące tę trójkę problemów, stanowią bardzo 
ważny problem badawczy wiążąoy się z metodami projektowania i 
automatyzaoji procesów projektowania, z aspektem lingwistycz¬ 
nym systemów operaoyjnych. 

Na ozwartym miejscu wyliozymy problemy optymalizaoji i bada¬ 
nia jakości, Weryfikaoja, ozy jeszcze lepiej dowodzenie popraw¬ 
ności orzeczeń o systemach operacyjnych w zasadzie są metodami 
binarnymi. System spełnia wymagania albo ich nie spełnia. Teo¬ 
retycznie rzecz biorąo, można sobie pomyśleć, że w jednym oelu 
konstruujemy kilka systemów operaoyjnyoh. Wtedy powstaje pro¬ 
blem, który z nioh jest lepszy. Na to pytanie w tej chwili nie 
umiem rzetelnie odpowiedzieć. 

Piąty problem, który wydaje mi się godny uwagi badaczy, to 
zagadnienie współdziałania oprogramowania i sprzętu, i jak już 
mówiłem, zagadnienie to rozpatruję zwykle z punktu widzenia 
systemu operacyjnego. Jako przykład choiałbym podać następują¬ 
cy problem badawozy: ozy nie jest za dużym ograniozeniem to, 
że każde przerwanie maskuje wszystkie inne przerwania, ozy to 
nie wyniknęło z pewnego prymitywnego poglądu na budowę oprogra¬ 
mowania, jaki panował 12-15 lat temu, kiedy to dopiero konstru¬ 
owano pierwsze systemy przerwań. Innymi słowy, problem polega 
na zbadaniu jaką informację naprawdę trzeba przeohowywać w mo- 
menoie różnych przerwań i jakie kombinacje przerwań powinny 
być wzajemnie maskowane, bo napewno nie wszystkie. Z punktu 
widzenia systemu operacyjnego jest to problem oiekawy, badaw¬ 
ozy. A takich problemów, jak się dobrze przyjrzeć, jest bardzo 
dużo. 

I wreszoie szósty problem, to styk systemu operacyjnego z 
translatorami. Nie przebadano tego zagadnienia nawet w syste¬ 
mach tradyoyjnyoh, niekonwersaoyjnyoh, nie mówiąc już o syste¬ 
mach konwersacyjnych. Problem ten nosi również nazwę problemu 
wiązania parametrów. W każdym systemie i translatorze jest 
pewna liczba parametrów, które wymagają ustaleń, np. parame¬ 
try rozmieszczenia, adresaoji itp. Zagadnienie polega na okreś- 
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leniu, kiedy te parametry należy ustalić. Nie wiemy tego nawet 
w systemaoh tradyoyjnyoh, systemaoh wsadowyoh, systemaoh z po¬ 
działem ozasu, a w systemaoh konwersaoyjnyoh, gdzie wszystko 
może się zmieniać dynamioznie, ten styk translatora z systemem 
operacyjnym wymaga gruntownego przebadania. 

Na zakońozenie, spróbuję przepowiedzieć jakie będą nowe kie¬ 
runki badań systemów operaoyjnyoh w najbliższyoh lataoh. Po 
pierwsze, systemy operacyjne w krotnyoh systemaoh lioząoyoh, 
przy ozym krotność nie będzie rzędu kilku, kilkunastu ozy kil- 
kudziesięoiu, ale kilkuset ozy kilku tysięcy, np. system opera¬ 
cyjny dla systemu cyfrowego składająoego się z kilku tysięcy 
prooesorów. Nie mam tu na myśli prooesorów duźyoh, wielkioh ma¬ 
szyn, mam na myśli sieoi lioząoe. Wiąże się to bezpośrednio z 
metodologią programowania dla systemów o takim profilu. 

Po drugie, systemy operacyjne maszyn bezpamięoiowyoh, mam na 
nyśli maszyny bez pamięoi operaoyjnej, maszyny stanowiąoe jed¬ 
ną wielką maoierz lioząoo-pamiętająoą. 

I wreszoie ostatni problem, który wydaje mi się ważny na la¬ 
ta najbliższe - to systemy operacyjne dynamioznie, konwersaoy J- 
nie adjustowane. 
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BBOJtHOE CJI0B0 
PeąioMe 


riepe^uicjieHHe npumiH, no kotophm cjie,nyeT 3aiiHMaTBCH one- 
paiiHOHHHMH CHCTeMaMH, a hmchho: HeodxonHMOCTB paspadoTKH 
MHornx onepamioiima chctom jpifi pa3jnmHbix npnMeHeiralł MaJiux 
BHnucjiHTejiBHŁoc MauMH n msi HecTaHnapTHHx npiiMeHeHHii óojibuhdc 
BU^CJTHT eJIBHHX CHCTeM. IIpiIMepU OÓmeHayHHUX npodJIBM, KOTOptie 
BCTpe^aroTcn npn HCc;ienoBaHHii onepaimoHHHx CHCTeM, b tom qn- 
cjie: npoÓJieMH CHHxpoHH3axoiH He3aBHCiraHX npoueccoB, cbh 3 h Me- 
Kny KOHCTpyKimefi MauMHbi h ee MaTodecneneHueM, nepeHHTn© Ma- 
DMHoft $yHKuiiH nporpaMMHpoBaHUfi, HOBue sanaan onTHMH3amui. 
Ilepe^HCJieHHe u KpaTKuS aHajM3 HepeuieHHŁix npo&ieM H 3 otfjiacTH 
onepaiiHOHHKX CHCTeM: MeToumoi npoeKTHpoBamts, npoBepKH Kop- 
peKTHOCTH, OnTHMH3aH0K, MSTO^OB npHCnOCaCBMBaHIIH, MeTOUOB 
yjiygmeHHH KanecTBa, cbh3h Meamy KOHCTpyiuuiefó Maucmu u ee 
MaTOóecneneHHeM, B3anMOneiicTBiifl h ctłikobkh onepaunoHHHx chc- 
TeM H TpaHCJLHTOpOB. 

INTRODUCTION TO SYMPOSIUM 


Summary 


Practical reasons for research in operating systems are listed: the 
necessity to construct many operating systems for diversified applica- 
tions of rainicomputer systems and for nonstandard applications of com- 
puters. Some exaiaples of generał scientific problems arising in operat¬ 
ing systems inyestigations are given: cooperation of independent proces- 
ses, interface between hardware and software, swapping of software func- 
tions for hardware realizations, new kinds of optimization problems. 
Following unsolved problems in the area of operating systems are listed 
and briefly analysed: design methods, correctness, adaptation methods, 
optimization, hardware-software replacement and interface, interface 
between operating systems and compilers. 
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W pracy dokonano przeglądu metod rozwiązywania 

problemu synchronizacji. 

• Programowe rozwiązanie Dijkstry, w którym uży- 
to jedynie zmiennych logicznych i całkowitych 
oraz nie założono istnienia specjalnych instruk¬ 
cji języka wysokiego poziomu. 

• Formalizm Gilberta i Chandlera umożliwiający 
automatyczną weryfikację rozwiązania. 

• Propozycja Lampsona, który definiuje specjal¬ 
ne instrukcje maszynowe TSL i PRO ułatwiające 
synchronizację procesów współbieżnych. 

• Rozwiązanie problemu synchronizacji przy użyciu 
semaforów i operacji P i V Dijkstry. 

• Formalizm Habermanna, w którym można dowodzić 
własności rozwiązania danej synchronizacji. 


Spis treści 


1. WSTĘP 

2. Programowe rozwiązanie problemu wykluczania 

3. SEMAFORY 

4. FORMALIZM GILBERTA I CHANDLERA 

5. formalizm HABERMANNA 

6. sieci petri 

7. ZAKOŃCZENIE 

Li teratura 
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1. WSTĘP 

Ciągle rosnąco zapotrzebowanie na moc obliczeniową powodu¬ 
je, że buduje się coraz większe i coraz bardziej skomplikowa¬ 
ne systemy liczące. Wzrost złożoności współczesnych systemów 
zwiększa stopień skomplikowania ich systemów operacyjnych. 
Dotyczy to zwłaszcza systemów wieloprocesorowych, umożliwiają¬ 
cych jednoczesne wykonywanie wielu programów. W systemach tych 
występuje ostro problem synchronizacji procesów współbieżnych, 
stanowiący jeden z czynników oddziaływujących na złożoność sys¬ 
temu operaoy jnego. 

Można rozróżnić dwa sposoby współdziałania procesów: 

• wykluczanie 
« współpraca pi*zez bufor. 

Wykluczanie 

Procesy mają dostęp do wspólnego zbioru zmiennych. Problem 
wykluczania polega na takim zsynchronizowaniu procesów, aby 
w danej chwili tylko jeden proces działał na zmiennych ze 
wspólnego zbioru. Ten fragment procesu, który realizuje komu¬ 
nikację ze wspólnym zbiorem zmiennych przyjęto nazywać rejo¬ 
nem krytycznym. 

Współpraca przez bufor 

Są dwie klasy procesów. Procesy zwane nadajnikami, wytwarza¬ 
jące komunikaty oraz prooesy zwane odbiornikami, przetwarzają¬ 
ce komunikaty. Nadajnik po wytworzeniu komunikatu umieszcza go 
w buforze; odbiornik pobiera komunikat z buforu, a następnie 
przetwarza go. Pojemność buforu zależy od tego, jak dalece na¬ 
dajniki mają wyprzedzać w działaniu odbiorniki. 

Przy umieszczaniu komunikatu w buforze nadajnik i odbiornik 
powinny być zsynchronizowane ze względu na przepełnienie bufo¬ 
ru. Umieszczenie komunikatu musi być opóźnione, gdy w buforze 
nie ma wolnego miejsca; opóźnienie powinno ulec likwidacji po 
pojawieniu się wolnego miejsca. 
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Przy pobieraniu komunikatu nadajnik i odbiornik powinny być 
zsynchronizowane ze względu na pusty bufor. Pobranie komunika¬ 
tu musi być opóźnione, jeśli nie ma w buforze nieprzetworzonych 
komunikatów; opóźnienie powinno być usunięte po nadejśoiu pier¬ 
wszego komunikatu. 


W praoy [ 3 ] Dijkstra przeprowadził analizę i podał rozwią¬ 
zanie problemu wykluczania stosując wyłąoznie środki programo¬ 
we. Podejście Dijkstry omówiono w rozdziale 2 . 

Programowe rozwiązanie problemu wykluczania ma dwie wady: 

1 * rozwiązanie już dla dwóch procesów jest skomplikowane. 

Utrudniona jest w związku z tym analiza własności rozwiąza¬ 
nia, 

2 . występuje tzw. problem "aktywnego oczekiwania", co powoduje 
zmniejszenie efektywności funkcjonowania systemu procesów 
jako całości* 

Gilbert i Chandler[ 5 ] zastosowali aparat teorii automatów 
skończonych umożliwiająoy formalną analizę własności rozwiązań 
proolemu wykluczania. Formalizm ten omówiono w rozdziale 4. 
Drugą a wyżej wymienionych wad eliminuje propozyoja Lampsona 
[li] , którą omówiono w rozdziale 3 » Lampson zakłada istnienie 
specjalnego rozkazu maszyny - rozkazu TSL - ułatwiająoego syn¬ 
chronizację w odróżnieniu od wyżej wspomnianego rozwiązania 
Dijkstry, w którym synchronizację realizuje się za pomocą 
instrukcji występująoych w każdej maszynie, a mianowicie 
instrukcji nadawania wartości zmiennej i testowania zmiennej. 


Do grupy rozwiązań problemu synchronizacji, w któiyoh postu¬ 
luje się istnienie specjalnych operacji, można zaliozyć metodę 
synchronizacji za pomocą operaoji P i V wykonywanych na specjal¬ 
nych zmiennych zwanych semaforami, zaproponowaną przez Dijkstrę 
[?]• Metodę tę omówiono w rozdziale 3* 


V/ rozdziale 5 omówiono propozyoję Habermanna [ 7 ]» który po¬ 
dał formalną definicję operacji P i V oraz udowodnił twierdze— 
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nie umożliwiająoe dowodzenie, że dane rozwiązanie synchroniza¬ 
cji ma określoną własność. 

Rozdział 6 zawiera krótkie omówienie sieci Petri. 


2. PROGRAMOWE ROZWIĄZANIE PROBLEMU WYKLUCZANIA 

Rozważmy dwa prooesy cykliczne współbieżne, które w każdym 
cyklu korzystają ze wspólnego zbioru zmiennych. Aby współpraca 
między procesami była poprawna musi być spełniony 

Warunek 1 . W każdej chwili najwyżej jeden prooes może się znaj¬ 
dować w swym rejonie krytycznym. Rozwiązanie podamy w zmodyfi¬ 
kowanym ALGOL-u, a mianowicie zapis 

3o parbogin SI, S2,••• Sn parend Sn+1 
oznacza, że po wykonaniu instrukcji So następuje jednoczesno 
wykonywanie instrukcji SI, S2,..«, Sn. Instrukcja Sn+1 zostanie 
wykonana po wykonaniu wszystkich instrukcji SI, S2,..., Sn. 

Wersja 1 

begin integer turn; turn:=1; 
parbegin 

prooess 1s begin Lit if tum=2 then goto LI; 
critioal seotion 1; 
tum:=2; 

remainder of oycle 1; goto LI 
end 

prooess 2: begin L2i if tum=1 then goto L2; 
oritical section 2; 
turn:=1; 

remainder of cycle 2; goto L2 
end 

parend 

end 

Gdy zmienna tum=1 to oznacza, że prooes 1 wszedł do swego 
rejonu krytycznego. 
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Ponieważ w każdej ohwili turnsl lub 2 więo dla wersji 1 wa¬ 
runek 1 jest spełniony. Jednakże rozwiązanie to ma poważny man¬ 
kament, ponieważ narzuca cykl 

proces 1, prooes 2, prooes 1,. 

Gdy jeden z prooesów zatrzyma się w ozęści "remainder of oyole" 
(tylko taki stop jest dozwolony) powoduje to zatrzymanie się 
drugiego prooesu. Dlatego powinien być spełniony 


Warunek 2 . Zatrzymanie się procesu na zewnątrz rejonu krytycz¬ 
nego nie powinno mieć wpływu na działanie innyoh prooesów. 


Wersja 2 

begin integer ol, o2j 
o1;=1j o2:e1. 
parbegin 

prooess 1: begin Ali o1:=0; 

Lii if o2=0 tben goto Llj 
oritioal seotion 1; 
o1:=1} 

remainder of oycle 1$ goto Al 


end 

prooess 2: begin A2: o2:=0; 

L2t if o1=0 then goto L2; 
oritioal seotion 2; 
o2:=1} 

remainder of oyole 2; goto A2 


parend 


end 


end 


Łatwo sprawdzić, że wersja 2 spełnia warunek 1 i 2. Jest 
to jednak rozwiązanie nie do pr^j§oia, ze względu na nastę¬ 
pującą możliwość. Przypuśćmy, że wykonały się jednooześnie 
instrukoje c1:=0, o2:=0, wówozas żaden z prooesów nie wejdzie 
do swego rejonu krytyoznego. Dlatego wymaga się aby był speł— 
niony 

Warunek 5 . Decyzje odnośnie tego, który z prooesów ma wejść 
do swego rejonu krytyoznego musi być podjęta w skończonym 
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czasie. Poprawne — tzn. takie, które spełnia warunki 1, 2 i 5 
rozwiązanie problemu wykluczania dla dwóch procesów podał 
Th. J. Dekker (Dijkstra [3]) 

bogiń lnteger cl, o2, turn; 
ols=1ł c2:=1; turn:=1; 
parbogin 

prooess 1: bogiń Al: c1:=0; 

LI: if o2=0 then 

begin if tum=1 then goto LI; 
c1:=1; 

BI: if turn=2 then goto BI; 
goto Al 

ond 

critical seotion 1 ; 

turn:=2; o1:=1; 

remainder of cycle 1; goto Al 

ond 

prooess 2: begin A2: c2:=0{ 

L2: if c1=0 then 

begin if tum=2 then goto L2; 
c 2 := 15 

B2: if tum=1 then goto B2{ 
goto A2 

end 

critical section 2 ; 

turn:= 1 ; c 2 := 1 ; 

remainder of cycle 2 ; goto A 2 

end 

parend 

end 

Rozwiązanie to jest dość złożone i udowodnienie, że jest ono 
poprawne nie jest sprawą prostą. 

Sprawa jeszcze bardziej się komplikuje w wypadku współdzia¬ 
łania n procesów. Problem ton rozwiązał Dijkstra w [2]. Jak 
sam wyznał w [h] był to najtrudniejszy program jaki kiedykol¬ 
wiek napisał. Po opublikowaniu pracy [ 2 ] Knuth [lO] zauważył, 
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że w przypadku n, (n>2) prooesów warunek 3 jest niewystarcza¬ 
jący. Może się zdarzyć, że mimo spełnienia warunku 3 prooes 
może nigdy nie wejść do swego rejonu krytycznego, Knuth zmody¬ 
fikował warunek 3 następująco 

Warunek 3 '. Każdy proces, który zgłasza gotowość wejścia do 
swego rejonu krytycznego, musi do niego wejść w skończonym oza- 
sie. Rozwiązanie w ten sposób zmodyfikowanego problemu wyklu¬ 
czania dla n prooesów podał Knuth w [10] • 


3« SEMAFORY 

Przyczyną złożoności rozwiązania Dekkera jest fakt, że tes¬ 
towanie i nadawanie wartości zmiennej stanowią dwie niezależne 
ozynnośoi. Gdy jeden prooes testuje zmienną, to nie "wie 1 ' o 
tym, ozy w tym samym czasie inny prooes nie nadał tej zmiennej 
innej wartości. Chcąc wyeliminować tę przyozynę złożoności nie¬ 
którzy autorzy postulują istnienie speojalnyoh instrukcji ułat¬ 
wiających budowę aparatu synchronizacji prooesów. I tak Lampson 
[li] zakłada istnienie rozkazu TSL n, którego treść Jest nas- 
tępująoat Jeśli (n) < 0 to (LR) + 2, Jeśli (n) » 0 to -1— n 
i (LR) + i. 

Część testowa każdego prooesu, w której przeprowadza się 
badanie ozy prooes może wejść do swego rejonu krytycznego ma 
postać 

TSL LOCK CRITICAL* - 

SKO CRITICAL 
SKO * -2 

1-- LOCK 

Etykieta CRITICAL wskazuje poozątek oiągu rozkazów realizu- 
Jąoyoh rejon krytyozny» Gdy zawartość pamięci LOCK Jest ujem¬ 
na prooes "pętli się" wykonująo rozkazy TSL LOCK i SKO* -2 do 
ozasu, aż inny prooes uozyni miejsoe LOCK nieujemne, wówozas 
proces wejdzie do swego rejonu krytyoznego ładująo Jednocześ¬ 
nie -1 do miejsoa LOCK, blokująo tym samym wejśoie do rejonu 
krytycznego innym prooesom. Przed wyjśoiem z rejonu krytyoznego 
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proces wykonuje operację 1—►LOCK otwierając wejście do rejonu 
krytycznego, 

Dijkstra [4] postuluje istnienie instrukcji swap (a f b) , 
której wykonanie powoduje wymianę wartości zmiennyoh a i b. 
Sposób wykorzystania tego rozkazu ilustruje poniższy przykład 
zaczerpnięty z pracy [4] i tak zmodyfikowany, aby nie odbiegał 
w formie językowej od przykładów podanych w rozdziale 2. 

Rozważmy n procesów komunikujących się ze sobą przez 
wspólną zmienną x. Z każdym procesem związana jest "prywatna" 
zmienna loo, W każdej chwili tylko jedna spośród n+1 zmiennych 
ma wartość zero; pozostałe zmienne mają wartość jeden. Proces 
jest w swoim rejonie krytycznym, jeśli jego zmienna loc ma war¬ 
tość zero, Zakładająo, że na początku żaden z procesów nie jest 
w rejonie krytycznym, ożyli zmienna x ma wartość zero, struk¬ 
tura procesu ma postać 

begin integer loc; loo tal; 

Lt if loo 4 0 then begin swap (x, loc); goto L end 
critioal seotion; 
swap (x, loc); 
remainder of oycle 

end 

Obydwie propozycje ułatwiają wprawdzie rozwiązanie problemu 
wykluczania, ale nie eliminują "aktywnego oczekiwania"* Badanie 
ozy można wejść do rejonu krytycznego angażuje czas procesora, 
który w tym czasie mógłby robić coś bardziej pożytecznego* 

Aby uniknąć "aktywnego oczekiwania" Lampson podał następują¬ 
ce rozwiązanie. 

Gdy proces stwierdzi, że nie może wejść do rejonu krytycz¬ 
nego umieszcza siebie na liście (wakeup list) procesów oczeku¬ 
jących na wejście do rejonu krytycznego następnie zawiesza swo¬ 
je funkcjonowanie - zwalnia procesor. Proces opuszczający rejon 
krytyczny czyni to przez standardowy podprogram, który przeglą¬ 
da listę procesów oczekujących i "budzi" jeden z nich. Może się 
jednak zdarzyć, że w czasie gdy proces umieszcza się na liście 








Zesz. Speo. 


METODY OPISU SYNCHRONIZACJI PROCESÓW 


29 


zostanie przerwany, co jest niedopuszczalne. Aby tego uniknąć 
podprogramy komunikujące się z listą powinny być nieprzerywal- 
R e. Lampson proponuje instrukcję PRO, której zadaniem jest za¬ 
pewnienie, że w czasie krótkiego okresu czasu po wykonaniu PRO* 

a ) proces, który wykonał instrukcję PRO nie może utracić swego 
procesora lub być wywłaszczony K przez zegar 

t>) nie może być wykonana inna instrukcja PRO. 

Jeśli inny procesor chce wykonać PRO musi odczekać aż zakoń¬ 
czy się aktualne PRO. 

Czas trwania instrukcji zależy od adresowania pośredniego, 
dlatego też czas trwania instrukcji PRO najlepiej mierzyć w 
liczbie sięgnięć do pamięci. Lampson twierdzi, że 15 sięgnięć 
do pamięci wystarczy. 

Obie wyżej wspomniane próby rozwiązywania problemu synchro¬ 
nizacji są interesujące, niemniej jednak niemal powszechną apro* 
^atę uzyskał pomysł Dijkstry [5] polegający nai 

1 . wprowadzeniu specjalnyoh zmiennyoh typu integer, zwany oh 
semaforami 

2. wprowadzeniu specjalnych operaoji jednoargumentowych: 

p - operaoji i V - operacji, których argumentami mogą być 
jedynie semafory. 

Wartościami zmiennych typu semafor są liczby nieujemne. Gdy 
wartości semafora ograniczymy do zbioru jo, l|, to semafor na¬ 
zywamy binarnym. Semafory nie spełniające tego ograniczenia 
nazywamy ogólnymi. 

V - operacja. Operacja V (S) zwiększa wartość semafora Sol. 

p - operacja. Operaoja P(S) jest zdefiniowana następująco* 

- jeśli S / 0, to P(S) powoduje zmniejszenie wartości Sol 

- jeśli S = 0, to operacja P(S) nie zmienia wartości S i 
nie jest zakończona do czasu, gdy inny proces nie wykona 

_ operacji V na tym samym semaforze. 

■0 


W niniejszych materiałach słowo "wywłaszczenie" odpowiada angielskie¬ 
mu terminowi preemption. 
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Istotę tych operacji stanowi fakt, że są one "niepodzielne" 
w następującym sensie: realizacja operacji V(S) wymaga 3 krokófl 

1. pobranie zmiennej z pamięci (I dostęp do pamięci) 

2 . zwiększenie zmiennej o jeden 

3. umieszczenie zmiennej w pamięci (II dostęp do pamięci). 

Otóż niepodzielność polega na tym, że po rozpoczęciu wykonyj 
wania operacji V(S) dostęp do zmiennej S powinien być zablokowfl 
ny do chwili zakońozenia operacji. Podobna uwaga odnosi się do 
operacji P. W danej chwili operację P może zainiojować więcej 
niż jeden proces, gdy semafor uzyska wartość 1 jedna z tych ope 
racji zostanie zakończona. 

Przy.użyoiu operacji V i P problem wykluczania staje się 
trywialny. Odpowiednik rozwiązania Dekkera wygląda następują- 
oot 


begin integer free; free x= 1 ; 
parbegin 

process li begin LI: P (free); oritical section 1; V (fre ( 
remainder of oyole 1; goto LI 

end 

process 2: begin L2: P (free); oritical section 2 ;V (free) 
remainder of oycle 2; goto L2 

end 

parend 

end 

Prostotę rozwiązania uzyskano dzięki temu, że realizaoja P 
i V wymaga rozwiązania problemu wykluczania na "niższym pozio¬ 
mie, tj. gdy operujemy pojęciami "rozkaz maszyny", "dostęp do 
pamięci". Tak więc nastąpiło przesunięcie problemu wykluczania 
ze skali makro do skali mikro. Wydawać by się mogło, że istota 
problemu pozostaje bez zmian. Przy użyoiu operaoji P i V 
znacznie upraszcza się opis rozwiązania, a przez to problem 
synchronizacji uprowadza się do problemu realizacji tych dwóch 
operacji. Stanowi to jak gdyby "standaryzację" trudności wystę¬ 
pujących przy problemie synchronizacji. 
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, Dijkstra [3] udowodnił, że każdy problem, który można roz- 
J wiązać stosując semafory ogólne, można również rozwiązać za 
pomocą semaforów binarnych* 

Reasumując rozważania tego rozdziału można stwierdzić, że 
opierając się na elementarnych operacjach (TSL lub swap lub 
p i V) tworzy się aparat ułatwiający układanie programów syn- 
r* chronizująoych. Pewne próby badania poprawności takich progra- 
1$ mów zostaną omówione w następnych rozdziałach. 


>e 4. FORMALIZM GILBERTA I CHANDLERA 

Metoda ta zostanie przedstawiona na przykładzie analizy wer¬ 
sji 1 rozwiązania z rozdziału 2. Schemat czynnościowy wersji 1 
wygląda następująco 


*1 


Proces 1 



Rys. 1 
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Każdy z procesów składa się z trzech ozęśoij 

• ozęśó testowa, w której następuje badanie, ozy prooes może 
wejść do swego rejonu krytyoznego 

• rejon krytyczny 

• pozostała ozęśó prooesu 

Proces może być w jediym z trzech stanów, stan 2 odpowiada 
części testowej, stan 1 - rejonowi krytycznemu, stan 0 - pozo¬ 
stałej ozęśoi procesu. 

Maszyna to trójka (P,,, Pg* v) , gdzie P j[ są prooesami, a 
v jest zmienną sterującą. 

Stan maszyny to układ (p 1 p g ) (d), gdzie p n jest stanem prooe- 
su 1, p 2 “ stanem procesu 2, a d jest wartością zmiennej steru- 
jąoej. Dla omawianego przykładu maszyna (P^j, P 2 ; tum) ma 3 2 .2=: 
« 18 stanów, ponieważ p^ może przyjmować wartości 0, 1, 2, a 
tum przyjmuje wartości 1, 2. 

Poszozególne procesy opisuje się za pomocą tzw. p - produk- 


oji ("partial rule") • Na przykład prooes 
pująoymi p - produkcjami 

1 można opisać nastę- 

(0x) (x) —- (2x) (x) 

(4.1) 

(1x) (x)—*• (0x) (2) 

(4.2) 

(2x) (1) — 1 - (1x) (x) 

(4.3) 


Produkoja (4.1) oznacza, że prooes 1 może przejść od sta¬ 
nu 0 do stanu 2 niezależnie od tego w jakim stanie jest prooes 2 
(dlatego w miejsoe p 2 piszemy x)• 

Ponieważ zmienna sterująca nie jest ani testowana ani nie 
nadano jej nowej wartości, jej wartość jest nieznana zarówno 
przed, jak i po wykonaniu przejścia od stanu 0 do stanu 2. 

Produkcja (4.2) oznaoza, że wprawdzie przed przejśoiem od 
stanu 1 do stanu 0 wartość zmiennej sterującej jest nieznana, 
ale po wykonaniu tego kroku zmienna ma wartość 2. 

Aby nie pisać p - produkcji nie wnoszących nio nowego wyma¬ 
ga się, aby p - produkcja zawierała albo zmianę stanu, albo na¬ 
danie wartośoi zmiennej* Dlatego p - produkcja 
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•(2x) (x) 


(2x) (2)- 
zośtała pominięta. 


Analogicznie p - produkcje procesu 2 mają postać 

(xO) (x)—-(x2) (x) (4.4) 

(xl) (x)—-(x0) (1) . ( 4 . 5 ) 

(x 2 ) ( 2 ) — (x 1 ) (x) ( 4 . 6 ) 

Zbiory p - produkcji generują produkcje opisująoe działanie 
maszyny jako oałośoi. 

Sposób generowania produkcji zależy od tego, ozy procesy 
działają jednooześnie czy niejednocześnie. 


1 . Działanie niejednoczesne 

Niech IL|, będą p - produkcjami procesów f P^• Produk¬ 

cja S=>S' jest dopuszczalna, gdy 

9 -) spełnia ograniczenie narzucone przez jedną z R^ 
b) poza zmianami wartości wynikającymi z R^ wszystkie pozosta¬ 
łe wartości są identyczne w S i S' 
o) S ^ S' 

Dla procesu 1 p - produkcje generują następujące produkcje 


(0x) 

(x) (2x)(x) 

(1x)(x) --(0x) (2) 

(00) 

(1) =>(20) (1) 

(10) (1) = 

=>(00)(2) 

(00) 

(2) =>(20) (2) 

(10) (2) = 

=>(00)(2) 

(01) 

(1) =>(21) (1) 

(11) (1) — 

^(01)(2) 

(01) 

(2) =>(21) (2) 

(11)(2) = 

=>(01)(2) 

(02) 

(1) =>(22)(1) 

(12)(1) = 

=^(02) (2) 

(02) 

(2) =>(22) (2) 

(12)(2) = 

=>(02)(2) 


(2x)(1) ■ 

—~(1x)(x) 



(20)(1) 

=i>(10)(1) 



(21)(1) 

=>(11)0) 



(22)(1) 

=>(12)(1) 



Analogicznie można wypisać produkcje dla procesu 2. 
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II* Działanie jednoozesne 


Nie oh będą dane p — prod ukoję 

Cp^I (a) ■■(p^ 3c) (o) dla prooesu 1 

(x Pg) (b)—PgXd) dla prooesu 2 

Taka para nie generuje produkóji jeśli jest spełniony wa¬ 
runek 

Wlia J b (a J x i b 4 x) lub o^d (o x i d ✓ x) 
Gdy warunek W1 nie jest spełniony, to otrzymujengr pzodukoję 
(P 1 Pg)(w) '^(p^, Pg) (z) 

gdzie 


w ■ 


a jeśli a x 
b jeśli b *i x 

1, 2 jeśli a ■ b ■ x (tworzy się dwie produkoje dla 

zmiennej = 1 i zmiennej a 2) 


z M 


o jeśli o |/ x 
d jeśli d 4 x 
w jeśli o a d a x 


Stosująo tę regułę otrzymujemy dalsze produkoje 


rf* / 
/ * 

(xO) (xKx2Xx) 

(x1)(x)»(x0) (1) 

(x2).(2)-r(xl) (x) 

(Ox) (x)—(2xXx) 

(00)(1) =0(22X1) 
(00X2) “>(22X2) 

(01X1)=>(20) (1) 
(01X2) ==>(20) (1) 

(02) (2)=>(21) (2) 

(1x) (x)-*(0*X2) 

(10X1) =>(02X2) 
(10X2) =>(02X2) 


(12) (2)=>(01) (2) 

(2x) (1)—(1xXx) 

(20X1)=^>(12X1) 

(21)(1) =>(10) (1) 



Łąoząo uzyskane produkoje otrzymujemy następujący opis dzia¬ 
łania maezyny. 
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Tabela 1 



(xO)(xMx2Xx) 

(x1)(xHxO)(1) 

(x2X2Hx1Xx) 

NIE DZIAŁA 

(0xXxW2xXx) 

(00)(1>*(22X1) 

(00X2)=K22X2) 

(01)(1M20)(1) 

(01X2M20)(1) 

(02)(2M21)(2) 

(00)(1)M20)(1) 

(00)(2M(20X2) 

(01)(1H21)(1) 

(01X2>»(21X2) 

(02)(1)=*(22)(1) 

(02X2)=K22X2) 

(1x)(xM0x)(2) 

(10)(1H02)(2) 

(10)(2H02)(2) 


(12)(2h(0lX2) 

(10) (1)=»(00X2) 
(10X2M00)(2) 

(11) (lM01)(2) 

(11) (2)-K01)(2) 

(12) (1K02)(2) 
(12)(2M02)(2) 

(2x)(1)-(ix)(x) 

(20)(1)=K12)(1) 

(21)(1H10)(1) 


(20)(1H10)(1) 
(21 )(i Mi 
(22)(1M12)(1) 

nie działa 

(00)(1)=*(02)(1) 

(00X2K02)(2) 

(10)(1)=»(12)(1) 

(10)(2)=>(12X2) 

(20)(1)=>(22)(1) 

(20X2M22)(2) 

(01)(1)=K00)(1) 

(01)(2M00)(1) 

(11)(1)=>(10)(1) 

(11)(2)o(l0)(1) 

(21)(1)=>(20)(1) 

(21)(2M20)(1) 

(02)(2)=*(01)(2) 

(12)(2X»(11)(2) 

(22)(2)=>(12)(2) 



Na podstawie tej tabeli można narysować graf przejść uwzgłęd- 
fliająo fakt, że stanem początkowym jest stan (22)(1). 

Stanem zabronionym nazywamy stan, w którym obydwa procesy są 
w swych rejonaoh krytycznych. A zatem zbiór stanów zabronionyoh 
E ■ {(H)(1), (11)(2)| . 

Nieoh S Q będzie stanem początkowym maszyny. Jeśli istnieje 
oiąg produkoji S 0 =>S 1 , S 1 =>S 2 ,..., S k _ 1 => S k , to piszemy 

==> S k i mówimy, że stan S k jest osiągalcy• 
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Nieoh Q będzie zbiorem wszystkioh możliwy oh stanów maszyny, 
wówozas zbiór produkoji T dzieli zbiór Q na dwa zbiory rozłąozne 

Q = A (T)u A 1 (T) 

gdzie 

A (T) = (S£Q * S 0 =^>s)u {S 0 } 
a^t) » {seq l S*A (T)} 

Maszyna jest poprawna gdy En A (T) a O. 

Sprawdźmy ozy rozważana maszyna jest poprawna. W tym oelu na¬ 
leży sprawdzić, ozy zaobodzi relaoja S Q =^=> (11)(1) lub 
B 0 =£=>(11)(2). Na podstawie tabeli 1 stwierdzamy, że 
(2l)(l)=b(1l)(1) i (12)(2)=>( 11)(2). 



Rys. 2 
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"Cofająo" się w ten sposób otr^mujemy 

(01) (1)=^>(11)(1) i (10)(2) =»(11)(2) 

Łatwo sprawdzić, że żaden ze stanów (01)(1), (10)(2) nie jest 
osiągalny, a więo nasza maszyna jest poprawna. 

Przedstawiona metoda umożliwia przeprowadzenie analizy na 
“aszynie oyfrowej. I tak autorzy praoy [5] podają, że pr^ za¬ 
łożeniu niejednoozesnoóoi przeanalizowano maszynę składająoą 
8 1§ z 3 prooesów i mająoą 1900 osiągalnyoh stanów. Analiza 
trwała 2,5 minuty na maszynie IBM 360/65. 

5 ,. formalizm habermanna 

Interesująoą próbę stwierdzenia poprawnośoi synchronizaoji 
prooesów podał Habermann [7], Synchronizaoję opisuje on za po- 
mooą operaoji wait (s) i signal (s), któryoh znaozenie jest ta¬ 
kie samo jak operaoji P (S) i V(S). 

Zatem majmy dwie operaoje wait (s) i signal (s) , rozważajmy 
poza tym stan synohronizaoji opisany stałą o [s] oraz zmiennymi 
nw(s) , ns(s), np(s) z poozątkowymi wartościami zerowymi, które 
oznaozają; 

nw(s) - liozba wykonań operaoji wait (s) 
ns(s) - liozba wykonań operaoji signal (s) 

n P(e) - liozba wykonań instrukcji znajdująoej się za instruk- 
oją wait (s) . 

Efektem wykonania wait (s) jest: 

nw(s) i= nw(s) + 1; _if nw(s) < o [s]+ ns(s) 

then np(s) i= np(s) + 1 

Wykonanie wait (s) nie powoduje opóźnienia, gdy jest spełniony 
warunek nw (s) < o[s] + ns (s) 

Efektem wykonania signal (s) jestł 

if nw (s) > c[s]+ ns(s) then np (s) t = np(s) + 1; 

ns(B) := ns (s) + 1 
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Habermann udowodnił następująoe twierdzenie: 

Twierdzenie . 

Relaoja 

np (s) = min (nw(s) , o [ s] + ns. (s)) (H) 

jest nieznlennioza zarówno względem operaoji wait (s) , jak i 
operaoji signal (s) . 

Opierająo się na tym twierdzeniu można dowodzić, ozy dana 
synchronizaoja jest poprawna. 

Przykład 1. Rozważny synohronizaoję prooesów w wypadku proble¬ 
mu wykluozania. 

Rejony kiytyozne prooesów komunikująoe się ze wspólnym zbio¬ 
rem danyoh s można zaprogramować w postaoi 

wait (s)i Zlj..., Zn; signal (8) 

gdzie Zł, Z2. Zn są operaojami na zbiorze s. 

Zakłada się, że o [s] = 1. 

Przy dowodzeniu poprawnośoi funkcjonowania rejonu krytyozne- 
go zakłada się, że niemożliwe jest wejśoie lub opuszozenie re¬ 
jonu krytyoznego pomijająo operaoje wait i signal. 

Rejon krytyozny funkcjonuje poprawnie, gdy 

a) tylko jeden rejon krytyozny może być wykonywany w danej 
ohwili 

b) żaden prooes nie będzie opóźniony, jeśli żaden z nioh nie 
znajduje się w rejonie krytyoznym 

Dowód a. Z relaoji (H) wynika 

np (s) < 1 + ns (s) 

tzn. liozba wejść do rejonu krytyoznego nie przekraoza liczby 
wyjść z rejonu krytyoznego zwiększonej o jeden 

np (s) - ns (s) < 1 

Dowód b. W wypadku istnienia prooesów opóźnianyoh zachodzi 
nw (s) >1 + ns (s) ożyli z relacji (H) wynika, że 
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np (s) = 1 + na (s) 

Z drugiej strony łatwo zauważyć, że gdy żaden proces nie jest 
w rejonie krytyoznym, to np (s) = ns (s). 

Przykład 2. Rozważmy dwa prooesy asynchroniozne, nadajnik S 
i odbiornik R komunikująoe się przez bufor pierścieniowy 
(rys. 5). 


REAR 



Z buforem związane są dwie zmienne FRONT i REAR. Zmienna 
FRONT wskazuje pierwsze wolne miejsce, natomiast zmienna REAR 
- pierwsze zajęte miejsoe. Stan poozątkowy buforu jest taki, 
że suoo (REAR) = FRONT, gdzie suco jest funkoją następnika. 
Wielkość buforu określa zmienna "bufsize". 

Po przygotowaniu przez S komunikatu d zostaje on umieszczo¬ 
ny w buforze 

deposit: buffer [FRONT] t= d; 

FRONT:= suoo (FRONT) 

Przed pi’zetworżeniem przez R komunikat r zostaje pobrany z 
buforu 

aooept: REAR := suoo (REAR) 
r := buffer [ REAR] 

Synohronizaoję ze względu na przepełnienie buforu przy ope- 
raoji deposit realizujemy wprowadzająo zmienną "frame", przy 
ozyra c [frame] = bufsize. 
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Synohronizaoję ze względu na pusty bufor przy oparaoji aooept 
realizujemy wprowadzając zmienną "messaga", przy czym o [mess- 
age] :: O 

depositt wait (frame); 

buffer [FRONT] :» d; 

FRONT : = suoo (FRONT); 
signal (message) 
aooept: wait (message); 

REAR «* suoo (REAR); 
r i* buffer [ REAR] ; 
signal (frame) 

Nie można dopuśoić do tego, aby kilka nadajników umieszoza- 
ło jednoozeAnie komunikaty do buforu lub też kilka odbiorników 
pobierało komunikaty. Dlatego operaoje depoait i aooept trzeba 
zaprogramować jako rejony krytyozne. Uozyniny to za pomooą 
zmienny oh "input" i "output", gdzie o [input] = o [output] =1. 

Ostateozna wersja prooedur jest następująoai 

prooedure deposit (d); 
begin - 

wait (input); 
wait (frame); 
buffer [FRONT] : =» d; 

FRONT := suoo (FRONT); 
signal (message) ; 
signal (input) 
end 

prooedure aooept (r) ; 
be gin 

wait (output); 

wait (message); 

REAR ta suoo (REAR); 
r t 3 buffer [ REAR]; 
signal (frame) ; 
signal (output) 

end 
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Posługując się relacją (H) można udowodnić pewne własności 
tak rozwiązanej synchronizacji 

1 * Przy jednoczesnym umieszczaniu i pobieraniu komunikatu z bu¬ 
foru zmienne FRONT i REAR nie wskazują tego 9amego miejsca. 

2 . Nie powstanie sytuacja kiedy: 

- liczba umieszozeń przekracza liczbę pobrań zwiększoną o 
bufsize 

- liczba pobrań przekraoza liczbę umieszczeń 

3 . Nie powstanie blokada. 

Udowodnimy własność 1. Nieoh fiu oznaozają liczby wykonań 
operaoji suoo na zmiennych FRONT i REAR. 

Gdy komunikat jest umieszozary, tzn# gdy wykonywana jest 
operaoja buffer [FRONT] : a d 
wówczas 

f = ns (message) ( 5 * 1 ) 

W tym czasie zachodzi 

ns (message) a np (frame)- bufsize + ns (frame) - 1 (5*2) 

na mocy treści procedury deposit i relacji (H). 

Gdy komunikat jest pobierany, tzn. gdy r := buffer [REAR] 
wówozas 


u a np (message) 


( 5 . 3 ) 


oraz 


np (meBsage) = ns (frame) + ns (meBsage) (5.4) 
na mooy treści prooedury aooept i relaoji (H). 

Uwzględniając (5.1) i (5-3) wzór 7 (5.2) i (5.4) można napi¬ 
sać w postaoi 

f = np (frame) - 1 < bufsize + ns (frame) - 1 ( 5 . 5 ) 
u = ns (frame) + 1 < f (5*b) 

Gdy umieszczanie i pobieranie odbywa się Jednocześnie, wów- 
czas pisząc wzór (5*5) w postaoi 
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f 4 bufsize + (ns (frame) + 1 ) - 2 ' ( 5 . 7 ) 

i uwzględniająo w nim wzór ( 5 * 6 ) otrzymujemy 

f ^ bufsize + u - 2 ( 5 . 8 ) 

uwzględniając w tym wzorze wzór ( 5 . 6 ) mamy 
u f ^ bufsize + u - 2 

czyli 

0 < f - u £ bufsize - 2 ( 5 . 9 ) 

Zmienne FRONT i KEAR wskazują ten sam obszar buforu, gdy 

u = f + 1 (mod bufsize) (5*10) 

Ponieważ wzoiy (5*9) i (5*10) są sprzeczne,FROWT i HEAR nie 
mogą wskazywać tego samego obszaru. 

6 . SIECI FETRI 

Opis systemu lioząoego w foimaliźmie sieoi Petri umożliwia 
dynamiczną analizę zachowania się systemu. 

Sieć Petri jest grafem zorientowanym mająoym dwa typy wierz¬ 
chołków: wierzohołki zwane miejsoami i wierzohołki zwane przejś¬ 
ciami. 

Przykład 1. Rozważmy sieć przedstawioną na rys. 4. 


K B 



Rys. 4 
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A, B, C, D - miejsca 

^* 2* 3 _ przejścia 

Miejsca A i B są wejśoiami przejścia 2 

Miejsoa C i D są wyjściami przejśoia 2. 

Znakowaniem sieci nazywamy funkcję 
f t P •* N t gdzie P jest zbiorem miejso 

a N = {o, 1 , 2 ,...] 

W przykładzie 1 f(A) = 1, f (c) = O 

Przejście t jest potencjalnie aktywne, jeśli dla każdego wejś- 
°ia p przejścia t zachodzi f (p) > O. 

Na przejśoiu potenojalnie aktywnym można wykonać operaoję 
strzelania. Efekt operacji strzelania ilustruje rys. 5» 




a/ stan sieci przód wykonaniem operacji strzelania, 
b stan sieci po wykonaniu operacji strzelania 



Przy opisywaniu systemu za pomocą sieoi miejscu odpowiada 
warunek*, Gdy miejsce zawiera kropkę oznacza to, że warunek 
jest spełniony. 

Stan systemu jest określony przez sieć wraz ze znakowaniem, 
oo oznacza, że zachodzą jednocześnie wszystkie warunki odpo¬ 
wiadające miejscom oznakowanym* Wykonanie operacji strzelania 
powoduje przejście do nowego znakowania, które określa nowy 
stan systemu* Przy czym zakłada się, że operacja strzelania 
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nie wymaga czasu, przejście od jednego stanu do drugiego jest 
natyobmiastowe• Czas jest związany z zachodzeniem danego warun¬ 
ku (ozas poty tu kropki w danym miejscu). 

Historię symulacji sieci opisuje się za pomooą o-grafów. 
O-graf sieci z przykładu 1 przedstawia rys. 6. 



Miejsoom sieoi odpowiadają krawędzie o-grafu, przejśoiom - 
odpowiadają wierzchołki o—grafu. 

W okresie I zaohodzą jednooześnie warunki A i B, w okresie II 
- warunki C i D itd. 

Gdy miejsce sieoi jest wejściem do dwóoh lub więoej przejść 
i każde z tych przejść jest potencjalnie aktywne, wówczas 
przejścia te nazywany konfliktowymi. 

Przykład 2. Rozważny sieć przedstawioną na xys. 7. 

Przejścia 1, 2 są konfliktowe. W takiej sytuacji tylko na 
jednym przejściu można wykonać operację strzelania. O-graf 
sieci z rys. 7 przedstawiono na iys. 8. 

Interesująoa byłaby możliwość badania dynamicznych własnoś¬ 
ci systemu opisanego za pomooą sieoi Petri na podstawie samej 
struktury sieoi (z pominięoiem symulacji). Badania w tym kie¬ 
runku przeprowadził Tourlakis [ij]• 

Nieoh S będzie podzbiorem miejso sieci Petri. 
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Rys. 7 



Rys. 8 
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Nieoh RS oznacza zbiór przejść, dla których elementy* zbio¬ 
ru S są wyjściami. 

Nieoh SR oznacza zbiór przejść, któiych wejścia należą do 
zbioru S. 

Zbiór miejso S^ spełniający warunek RS,j S S^R nazywamy blo¬ 
kadą. Każde strzelanie, które umieszcza kropki w wymaga, 
aby kropki były uprzednio w S^ • Jeśli więc nie ma kropek w S^, 
to żadne strzelanie nie może umieścić kropki w S^. 

Zbiór miejso S£ spełniający warunek S^R ^ RS 2 nazywamy pu¬ 
łapką. Każde strzelanie, które wymaga istnienia kropek w S£ 
umieszcza kropki w S 2 * Tak więc jeśli są kropki w S 2 , to żadne 
strzelanie nie może usunąć wszystkich kropek z 

Znakowanie M nazywamy pseudo żywym, jeśli każde znakowanie 
uzyskane z M zawiera przejście potencjalnie aktywne. 

Tourlakis udowodnił następujące twierdzenie: 

Twierdzenie. Nieoh sieć Petri ma tę własność, że każda blokada 
zawiera pułapkę. Wówczas każde znakowanie, które umieszcza 00 
najmniej jedną kropkę w każdej pułapce jest pseudo żywe. 

7. ZAKOŃCZENIE 

Omówione w rozdziałaah 4 i 5 metody formalnego opisu synchro- 
nizacji są raczej niezadowalające i stanowią pierwsze próby roz¬ 
wiązania tego trudnego problemu. 

Gilbert i Chandler zaproponowali wprawdzie formalny opis 
synchronizacji umożliwiający pełną analizę, ale jest on bardzo 
pracochłonny • 

Habermhnn pokazał, że można dowodzić poprawności programów 
synchronizujących, i uczynił pierwszy krok w rozwiązaniu proble¬ 
mu syntezy synohronizaoji; niemniej jednak dowody są skompliko¬ 
wane a prezentacja metody syntezy ogranicza się jedynie do roz¬ 
wiązania kilku przykładów. 
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Niektórzy autorzy wiążą duże nadzieje na rozwiązanie proble- 
mu synchronizaoji z sieoiami Petri. Jednakże trudno ustosunko- 
w ać się do tego poglądu, ponieważ jest w chwili obecnej niejas¬ 
ny związek między sieciami Petri a programowaniem synchroniza¬ 
cji. 


Wobec braku odpowiednioh metod programuje się nie dowodząc 
Poprawności, a to powoduje istnienie błędnych programów. Jed- 
n i 2 konsekwenoji istnienia błędu w synchronizacji jest możli¬ 
wość powstania blokady. Poniżej krótko ten problem omówinjy. 

Załóżny, że są dwa prooesy A i B oraz dwa zasoby a, b. Z da- 
nogo zasobu w danej ohwili nie może korzystać więcej niż jeden 
Prooes. Zasób może być zwolniony jedynie przez prooes, który go 
2 a jął. Przy tych założeniach typową sytuację blokady ilustruje 

rysunek 


Prooes B 

żądanie b 

żądanie a 

zwolnienie b 

Przypuśćmy, że proces A zajął zasób a i proces B zajął za- 
s ^b b, następnie proces A zgłasza zapotrzebowanie na zasób b, 
natomiast proces B zgłasza zapotrzebowanie na a. Prooes A jest 
Zablokowany, bo dostęp do zasobu b może uzyskać dopiero po 
zwolnieniu go przez prooes B. Prooes B zwolni zasób b po uzys¬ 
kaniu dostępu do zasobu a, zajętego przez proces A. Tak więc 
°ba procesy nawzajem się blokują. 

W każdym systemie, w którym procesy dzielą zasoby trzeba 
^stosunkować się do problemu blokady. Są trzy możliwości: 

^• Zapobieganie. 

System jest zaprojektowany w ten sposób, że powstanie blo¬ 
kady jest niemożliwe. 


Proces A 
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2 . Wykrywanie, 

Stan blokady może powstać, ale jest automatycznie wykrywany# 
Wyjście z tego stanu polega na wymuszeniu zakońozenia zablo¬ 
kowanych prooesów lub też uwolnienia zasobów przypisanych 
zablokowanym prooesom. 

Katastrofa# 

Blokada może powstać i nie jest automatycznie wykrywana. Ooe- 
nę ozy powstał stan blokady i ewentualne środki zaradcze po¬ 
zostawiono w gestii operatora. 

W [i] Coffman, Elphiok, Shoshani sformułowali warunki konieoZ' 
ne do tego, aby w systemie mogła powstać blokada. Jedną z metod 
zabezpieczenia się przed powstaniem blokady w systemie jest za¬ 
projektowanie systemu w ten sposób, aby nie był spełniony jeden 
z wyżej wspomnianych warunków. Taką metodę zastosowali Murphy 
[12] , Mavender [8] i Habermann [6j. Praoe ty oh autorów mają 

oharakter przyczynków, natomiast analizę problemu blokady 
z teoretyoznego punktu widzenia przeprowadził w swej rozprawie 
doktorskiej Holt [ 9]• 
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METOAdI nPEUCTABJIEHM CHHXP0HM3AUWW IIPOUECGOB 
Pęgme 


TjiaBHoe 3aTpyflH6HHe b noHMMaHHH <py hkuhoH upoBawia cjioamoft 
BUMHCJIHTGJILHOił CHCT6MŁI 3atUQ0Ha6TCA B IipodJieMe OHHXpOHH3amtH 
ópoueccoB. 

B HaoToameM Tpy^e aaeTCH od3op mbtoaob peuieEuw npo&neMU 
CHHXpOHH3amiH: 

1. IIporpaMHoe peine Hue AattKOTpu, b kotopom ncnojiB30BaHH 
AHint jiorinecKHe h uejme nepeMemme, a Tarae He npeji- 
jiaraioTCfl HHKaKue cneujiajiBHue HHCTpyKmm H3HKa bhoo- 
Koro ypoBHA. 

2. ®opMajni3M JbuuiBÓepTa u ^amwiepa, no3BOJunowHtt aBTOMa- 
THsnpoBaTB npoBepity pememtH. 

3. IIpejyiomeHiie JlaMncoHa, onpeflejiHjomee onemiaJiBHHe HHCTpy- 
kujdi T3L h pro, oOjier^ajoiwie CHHxpoHM3amno napajueja- 
hhx npoueocoB. 

4. Peraemie npoÓJieMu CHHxpoHH3amm npa ncnojiB30BaHnn oe- 
Ma&opoB h onepaiiHfl P hV flaftKCTpu. 

5. $0pMaJIM3M PaóepMaHHa, B KOTOpOM MO&HO JJOKaSUBaTB OBOtt- 
CTBa penieroifl flaHHOft CHHxpoHH3aiBm. 
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d ESCRIPTION methods of process synchronization 


Difficulties in gaining an understanding of the behaviour of a oom- 
Plex Computer system come from the problem of process synchronization. 

This paper presents a survey of different approaches to tho synchroni- 
sation problem. 

The programmed solution of Dijksira in which only logical and integer 
Yariables are used; there is no extension to the usual statements of 
high-level languages. 

The analysis formalism of Gilbert and Chandler allowing a mechanical 
proof procedura which will either verify or discredit any solution. 

3* The proposal of Lampson who defines the epecial machinę instructions 
TSL and PRO to facilitate synchronization between concurrent proces- 
ses. 

The solution to the process synchronization by means of semaphores 
and P and V operations introduced by Dijkstra. 

The formalism of Habermann in which we can precisely prove properties 
of a given synchronization. 
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SYNCHRONIZACJA PROCESÓW W MASZYNIE CYFROWEJ 
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Pracę złożono 10.1*1974 


d a Postawie ogólnej definicji procesu wprowa— 
*°no pojęcia procesu programowanego i monito- 
• Pr oces programowany Jest szeregową kombi- 
°ją procesów podstawowych odpowiadających 
^ftstrukcjom programu. Monitor Jest procesem 
^y&chronizującym dla procesów programowanych 
2e *nętrznych. Przedstawiono dwa algorytmy 
R mów rozkazowych procesora. Pierwszy opisuje 
•Piętowy monitor o minimalnym i kompletnym 
lorze funkcji synchronizujących. Drugi jest 
fforytmem cyklu rozkazowego procesora wir- 
u *lnego jako własnego procesora każdego pro- 
8 bu programowanego* 


Spis treści 

1ł MONITOR 1 PROCES PROGRAMOWANY 
2 * MONITOR minimalny 

Przykład realizacji monitora 
procesor wirtualny dla procesu programowanego 
5 * PODSUMOWANIE 
literatura 


1 » monitor i proces programowany 

Aby ogarnąć złożoność problemów przy zaohowaniu się prooe- 
Q ora wyposażonego w układ przerwań definiuje się pojęoie pro' 
° B8 ń. Jako intuioy jną podstawę podziału ozynnośoi na procesy 
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przyjmuje się zasadę "ciągłości" licznika rozkazów. Zgodnie 
z tą zasadą jako następną operację prooesu przyjmuje się wy¬ 
konanie rozkazu o adresie wskazanym przez licznik rozkazów 
wyznaczony w trakcie wykonywania poprzedniego rozkazu tego 
prooesu. Eliminuje się więc jako oboe dla prooesu te oiągi 
rozkazów, które zostały wywołane przez niezwiązane z tym pro¬ 
cesem przerwania. 

Przy rozpatrywaniu własności procesów trudno uzyskać właś- 
oiwą ogólność opisu działania samego prooesora, gdyż efekt 
działania prooesu zależy od wymienialnego programu. Z drugiej 
strony trudno rozdzielić operacje wohodzące w skład procesów 
od operaoji związanych z przełąozaniem procesora między pro- 
oesy. 

Rozwiązaniem pozwalającym wyeliminować te trudności może 
być podejście Horninga i Randella przedstawione w [i]. 

Pozwala ono z jednej strony dekomponować procesy, z dru¬ 
giej - pozwala traktować jako prooes kombinację procesów 
składowych. Jedną z możliwych form kombinacji jest ko m- 
binacja Bzeregowa. Tworzy ją zbiór procesów 
z tą własnośoią, że w każdym stanie najwyżej jeden proces jes t 
aktywny. 

Dalej Horning i Randell sugerują, aby wykonywanie konwencjo' 
nalnego programu sekwenoyjnego potraktować jako kombinaoję 
regową podstawowyoh procesów, z któryoh każdy jest zdefiniowa 
ny przez instrukcje programu* Ta kombinacja współdziała z pi^ 
oesem sterująoym, który określa instrukcję definiująoą kolejitf 
prooes podstawowy. Prooes sterująoy i kombinaoja prooesów pod" 
stawowych komunikuje się ze sobą przez zestaw wspólnyoh zmień" 
nyoh, zwanyoh statusem programu, w którym 
oentralną rolę gra licznik rozkazów. Ogólnie prooes sterująoy 
może współdziałać z kilkoma kombinacjami prooesów podstawowych^ 
(z któryoh każda posiada własny status), używającymi tego sam 
go prooesora w różnym czasie i synchronizującymi się wzajemnie' 



Zes 2. Spec. 


SYNCHRONIZACJA PROCESÓW... 


55 


Prooes sterujący nazywać będziemy dalej monitorem. 
Kombinację procesów podstawowych komunikująoą się z monitorem 
Za pomocą ustalonego zbioru zmiennyoh nazwiemy proce- 
9 9 m programowanym, zaś ten zbiór zmiennyoh - 
s ^atusem proc es u. 

Istotą tego podejśoia jest, zdaniem autora, potraktowanie 
m °nitora nawet w przypadku, gdy jest on realizowany metodą 
u ^ładowo-programową, nie na równi z procesem programowym, ale 
2 P^ooesem podstawowym* W stwierdzeniu tym zawarty jest więc 
P°stui a t; | aby działanie monitora traktować jako składnik cy- 
rozkazowego procesora, a co za tym idzie, aby jego reali- 
2a °ja była oałkowicie układowa. 

2 * MONITOR minimalni 

Aby powyższy postulat uozynić realnym, należy określić m±- 
aimai^y, ale kompletny zbiór funkoji monitora* Pomijająo funk- 
sterowania sekwencyjnego, którymi się tu zajmować nie bę- 
^zieny^ przyjmiemy jako kompletny zbiór funkcji monitora zestaw 
°Psracji monitora bazowego opisany przez Hansena w [2]. 

W skład monitora bazowego wohodzą operaojej 

• ^icjowania i końozenia prooesówj 

• w ait i signal na semaforaoh; 

• swait i oause na zdarzeniach (event variable). 

Nansen pokazuje jak na ioh bazie zrealizować konstrukcje 
^^ka programowania wysokiego poziomu takie jak proste i wa- 
r unkowe regiony kiytyozne oraz zdania współbieżne, które w spo— 
86b Zgodny i bezpieozny pozwalają pisać programy dla współ¬ 
istniej ąoyoh prooesów programowany oh [2], [3] • 

° k &zuje się, że konstrukoje te można zrealizować na bazie 
d Sż 0 skromniejszego monitora wykonującego jedynie operaoje 
Wal t i signal. 
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Poniżej przedstawimy sposób realizaoji regionów krytyoz- 
nyoh, w któryoh stosowane są openaoje await i oause. 

Posłużyć się w tym oelu językiem PASCAL [4] rozszerzonym 
o notaoję dla prosty oh regionów krytyoznyoh [2] w formie i re¬ 
gion t do 8, 

Zdefiniujemy najpierw typ zmiennej synchronizującej zwany 
bramką równoległą i trzy prooeduzy, które jako jedyne mogą 
działać na zmiennej tego typu (p. Algorytm 1). Składnik "w" 
zmiennej B będąoej parametrem ty oh prooedur gra więo rolę 
"zamka"t od którego stanu zależy, ozy prooes przez nią "prze- 
ohodząoy” będzie "przepuszozony" ozy "zatrzymany", zaś skład¬ 
nik "1” - rolę lioznika "zatrsymanyoh", gdy bramka jest zamk¬ 
nięta* Po otwaroiu "zamka" zwalniane są równolegle wszystkie 
prooesy zatrzymane, oo tłumaozy nazwę bramki* W tym kontekś¬ 
cie semafor można by nazwać bramką szeregową* 

ALGORCTM 1 

"OPERACJE SINCHRONIZACJI RÓWNOLEGŁEJ" 

type bramka równoległa = 
reoord 

bsshared reoord wt booleani li integer end| 
si semafor 

end 

{poozątkowo l=s=o} 

prooedure przejdź ( yąr Bt bramka równoległa); 
begin with B do 

begin region b do 

with b do if w then signal (s) else li«l+1| 
wait (s) 
end ; 

end 

prooedure zamknij ( var Bi bramka równoległa)i 
begin with B do 

region b do with b do wia false 

end 
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Prooeduro otwórz (var Bi bramka równoległa)} 
begin with B do 

region b do with b do 
begin 

w;» true ; 

while 1>0 ^o begin li= 1- 1; signal (s) end ». 
end; 
end 

Wówczas użyoie prooedur await i oause wewnątrz regionów kry¬ 
tycznych można zastąpić następująoo: 


£ęgion v do 


with v do 

bogiń 


begin 

while not W do 


wait (mutex); 

await (e); 


while not W do 

SI} 


begin 

end 


zamknij (B); 
signal (mutex)$ 
przejdź (B); 
wait (mutex) 



end; 



SI; signal (mutex) 



end ; 




Region v do 
begin 

S2; 

oause (e) 
and 


with v do 

begin 

wait (mutex); 

S2; 

otwórz (B) } i 



signal (mutex) 
enęj 


Zasadnioze postulaty dotyoząoe warunkowyoh regionów kiy- 
tyozryoh są spełnione, gdyż sprawdzanie warunku W odbywa 
8l t w obrębie regionu krytyoznego, zaś oozekiwanie poza Jego 
° b rębem. 
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Prooedury iniojowania i kończenia procesów można łatwo zbu¬ 
dować opierając się na buforze Btanów początkowych statusów 
inicjowanyoh prooesów. Nadawcami statusów do bufora są proce¬ 
sy inicjujące, zaś odbiorcami - procesy zakończone. 

Zauważmy dodatkowo, że synchronizacja procesu programowane¬ 
go z procesem działania urządzenia zewnętrznego również może 
być zrealizowana na bazie semaforów. Elegancki przykład roz¬ 
wiązania problemu podaje Habermann w [ 5 ] (patrz Algorytm 2 ). 
Procedura deposit (d) ładuje do bufora urządzenia meldunek d 
i nadaje sygnał startu urządzenia (signal (message)) • Działa¬ 
nie urządzenia jest zaś opisane procedurą accept. Urządzenie 
po otrzymaniu sygnału startu przetwarza meldunek, po czym na¬ 
daje sygnał końca pracy (signal (frame)) • Istotą tego podejś¬ 
cia jest utożsamienie operacji zgłoszenia przerwania z opera¬ 
cją signal. 


ALGOM TM 2 

11 SYNCHRONIZACJA PROCESU PROGRAMOWANEGO I ZEWNĘTRZNEGO 


procedurę deposit (d) ; 
begin 

wait (free) ; 
buffer:=d; 
signal (message) 5 
wait (frame); 
signal (free)5 

t>nd 


procedurę accept; 
begin 

wait (message) 5 
process (buffer); 
signal (frame) 5 

end 


3. PRZYKŁAD REALIZACJI MONITORA 

Wychodząc z przesłanek wymienionych powyżej, tzn. przyjmu¬ 
jąc jako minimalny, kompletny zbiór operacji monitora opera¬ 
cje wait i signal na semaforach, naszkicujemy poniżej ogólny 
zarys procedury obrazującej cykl rozkazowy procesora kompute¬ 
ra wieloprocesorowego z uwypukleniem funkcji monitora. 

Rozpatrujemy komputer składający się z u identycznych 
procesorów współpracujących ze wspólną pamięcią operacyjną. 
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W komputerze może być realizowany oh współbieżnie p prooesów 
Programowanych. Prooesy programowane synchronizują się wzajem¬ 
nie i z procesami zewnętrznymi za pośredniotwem s semaforów. 
Każdy z prooesów ma przypisany jeden z 1 poziomów prioryteto¬ 
wych, na podstawie którego monitor podejmuje decyzję o wywłasz- 
ozeniu procesu. Cykl rozkazowy każdego z procesorów przedstawia 
Algorytm J. W algorytmie zastosowano zapożyczoną od Hansena [2] 
botaoję dla zmiennej q typu kolejka, zawierająoej elementy ty- 
PU P podzielone na 1 poziomów priorytetowych o postaoi 
type L = I..I 5 
var q : gueue L of P; 

Prooedury wprowadź (p, l'q) oraz usuń (p,l,q) wprowadzają i 
Usuwają element p typu P z poziomu 1 kolejki q. Funkoja boo- 
lowska pilny (1, q) określa, ozy kolejka q zawiera element, 
który jest ważniejszy niż inny element o danym poziomie 1. 

Do obsługi semaforów zadeklarowanych przez 

semafor: arra.7 S of reoord 

lioznik: integer; 
ozekanie: queue L of P 
end 

wprowadzono funkoję boolowską zgłoszenie ( semafor ), która 
Przyjmuje wartość "true", gdy maoierz semafor zawiera co naj¬ 
mniej ,jeden element taki, że lioznik J O oraz kolejka ozeka- 
Si® nie jest pusta. 

Prooedura Identyfikuj ( przyozyna , semafor ) wyznaoza indeks 
(Przyczyna) typu S elementu maoierzy semafor, dla którego: 

lioznik 4 0 oraz kolejka ozekanie nie jest pusta. 

• Procedura wykonaj rozkaz ( status ,( prooes ) , wspólne , £a- 
mięć) wyznaoza i wykonuje jedną z operaoji przewidzianych w 
Uście rozkazów prooesora, a któryoh interesują nas dwie zwią- 
z&na z synohronizaoją a opisane w Algorytmie h. 

Prooes realizowany pod kontrolą przedstawionego monitora 
może znajdować się w jednym z trzeoh zasadniozyoh stanów: 
działanie, gotowość, zawieszenie. 
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Wpisanie identyfikatora prooesu do rejestru własnego proce* 
sora nazwanego "proces" (w wyniku wykonania procedury usuń 
(proęes, poziom , gotowość )) powoduje przejście prooesu w stan 
działania. Procesor wykonuje wtedy kolejno rozkazy wyznaozo- 
ne przez status tego procesu. 

Warunkiem konieoznym na to, aby prooes był w stanie działa* 
nia jest brak w kolejce gotowości procesu o poziomie ważniej- 
szym niż rozpatrywany prooes. 

W przeciwnym przypadku prooes przechodzi w stan gotowości, 
oo jest związane z wprowadzeniem identyfikatora procesu do 
kolejki gotowości, Ważniejszy prooes przechodzi wtedy w stan 
działania. 

Wykonanie przez prooes rozkazu zawierającego operaoję wait 
związane jest z przejściem prooesu w stan zawieszenia, oo po¬ 
lega na wprowadzeniu identyfikatora prooesu do kolejki czeka¬ 
nia semafora określonego przez parametr operacji. 

ALGORYTM 3 

"CYKL ROZKAZOWY PROCESORA FIZYCZNEGO" 

type 1.*p; 1»»łt S= 1#.s; 

T 1 = array P of status procesu; 

T 2 = reoord 

semafors array S of record 

licznik: integer; 
czekanie: queue # L of P 
end ; 

gotowość: queue L of P 
end 

procedurę cykl rozkazowy procesora ( var status: Tl; wspólne: 

shared T 2 ; pamięć T); 
yar prooes, nowy: P; 

poziom, pilność: L; 
przyczyna: S; 
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begin 

repeat 

region wspólne do with wspólne do 
begin 

while zgłoszenie (semafor) do 
begin 

identyfikuj (przyozyna, semafor); 
with semafor (przyozyna) do 
begin 

lioznikt= lioznik -1; 
usuń (nowy, pilność, ozekanie) 
end; 

wprowadź (nowy, pilność, gotowość) 
end; 

if pilny (poziom, gotowość) then 
begin 

wprowadź (prooes, poziom, gotowość); 
usuń (prooes, poziom, gotowość) 
end ; 
end; 

wykonaj rozkaz (status (proces;, wspólne, pamięć); 
forever 

end 

ALGORYTM 4 

OPERACJE SYNCHRONIZUJĄCE PROCESORA" 

££^£edure wait (s:S; var wspólne shared T 2 ; 
prooes: P; poziomi L); 

begin 

£?gion wspólne do with wspólne do 
begin 

with semafor (s) do 
wprowadź (prooes, poziom, czekanie); 
usuń (proces, poziom, gotowość) 
end; 

end 
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prooedure signal (s:S; var wspólne: shared T2 ); 
begin 

region wspólne do with wspólne do with semafor (s) do 
licznika lioznik + 1 

ond 

Ze stanu zawieszenia proces przeohodzi w stan gotowości po wy" 
braniu go z kolejki czekanie w przypadku gdy procesor wykryje* 
że lioznik semafora jest większy od zera. Wybranie jest zwią¬ 
zane ze zmniejszeniem lioznika o 1. Zwiększenie licznika o 1 
następuje w wyniku wykonania operacji signal przez proces pro¬ 
gramowany lub zewnętrzny. 


4. PROCESOR WIRTUALNY DLA PROCESU PRÓG RAMO:/ANEGO 

Przyjmująo t że czas zajętośoi regionów krytycznych zmien¬ 
nej "wspólne” jest pomijalnie mały w stosunku do czasu, w któ¬ 
rym regiony te są wolne, tak że przy wejściu do tych regio¬ 
nów nie tworzą się kolejki, działanie komputera składającego 
się z u procesorów, w których działa opisany powyżej moni¬ 
tor równov f ażne jest działaniu maszyny wirtualnej złożonej z 
p procesorów wirtualnych z dużo prostszymi logicznie monito¬ 
rami. Prostota logiczna osiągnięta została dzięki możliwości 
przydzielenia każdemu procesorowi programowanemu procesora 
wirtualnego, co dopuszcza realizację ich wzajemnej synchroni- 
zacji na bazie aktywnej formy czekania (busy fonu of waiting) 4 
Cykl rozkazowy procesora wirtualnego przedstawia Algorytm 5, 
natomiast operacje synchronizujące tego procesora - Algorytm 6* 
W Algorytmie 5 poza określonymi wcześniej procedurami zastoso¬ 
wano boolowską funkcję priorytet ( proces , czekanie ), która 
określa, ozy element proces ma maksymalny priorytet. Jako ele^ 
ment o maksymalnym priorytecie w kolejce traktuje się ten ele-* 
ment, który zostałby wybrany z tej kolejki przez procedurę 
usuń (proces, poziom, czekanie ) . Ponieważ procedura usuń (pro- 
ces, poziom , czekanie ) występuje wraz z funkcją priorytet 
( proces , czekanie ) w obrębie regionu krytycznego parametr 
"prooes" prooedury "cykl rozkazowy procesora" może być zdefi¬ 
niowany jako stały. 
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A^OHITM 5 

,,Cy KL ROZKAZOWY PROCESORA WIRTUALNEGO" 
procesor = 0; 

^£5 Ł=1..1; S=1.«s; VS= prooesor.. s; 

VT= array VS of reoord 

licznik: integer; 
czekanie: ąueue L of P 
end; 


Procedurę cykl rozkazowy v procesora (prooes: P; var v semafor: 
shared VT: pamięć: T); 
rejestry: status procesu; 
poziom: L; 

stan: (działanie, gotowość, zawieszenie); 

Procedurę v w &it (s: S; var v semafor: shared VT); 

czekaj: boolean; 

^£ein 

c zekaj:= true ; 

Region v semafor do with v semafor (s) do 
w staw (prooes, poziom, czekanie); 

£epeat 

region v semafor do with v semafor (s) do 

if priorytet (proces, czekanie) and licznik > 0 then 

^egin 

licznik:= licznik -1; 
usuń (prooes, poziom, czekanie) ; 
czekaj:= false 
end; 

untii not czekaj; 

end; 


E£2ęedure v signal (a: VS; var v semafor: shared VT); 

£egion v semafor do with v semafor (s) do 
licznik:= lioznik +1 

end; 
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begin 

repeat 

if stan= gotowość then 
begin 

v wait (prooesor, v semafor)* 
stan:= działanie 
end; 

wykonaj rozkaz (rejestry, v semafor, pamięć); 
if stan = działanie then 

region v semafor do wlth v semafor (prooesor) do 

if pilny (poziom, czekanie) then 

begin 

stania gotowośći 
v slgnal (prooesor, v semafor) 
end; 
foreyer 
end 

ALG OK TM 6 

"OPERACJE SYNCHRONIZUJĄCE PROCESORA WIRTUALNEGO" 

prooedure slgnal (s» S; var v semafor: shared VT); 
begin 

v signal (s, v semafor) 
end 

prooedure wait (si S; var v semafori shared VT, 

Stani (działanie, gotowość, ozakanie)) ; 

begin 

stania ozekanie; 
v signal (prooesor, v semafor); 
v wait (s, v semafor); 

Btam= gotowość 
end 
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PODSUMOWANIE 

Jeśli monitor realizowany jest metodą układowo-programową, 

Jego część programowa ma charakter procesu programowanego. 
Zauważmy jednak istotne różnice we właściwościach monitora 
Programowanego i procesu programowanego. Monitor programowany, 
Jakkolwiek posiada w r łasny status, współpracuje jednak z proce- 
0 em sterującym realizująoym jedynie funkcje sterowania sekwen- 
Q yjnego. Ograniczenie funkcji procesu sterującego do potrzeb 
m °nitora programowanego osiąga się zazwyczaj metodą zablokowa¬ 
na przerwań. Z tego powodu programową realizaoję monitora 
m °żna traktować jako swego rodzaju "wybieg" usuwający określo- 
ne braki prooesora. 

Minimalizaoja monitora poza względami natury ekonomicznej 
(“inimalizacja sprzętu do realizacji funkcji synchronizacji) 

aa duż e znaczenie również przy jego realizacji programowej. 

Pr\ 

,;Zw ala bowiem tworzyć złożone narzędzia synchronizacji o bu- 
d °wie strukturalnej i osiągnąć to f oo Dijkstra [6] nazywa moż- 
■^iwie najprostszą dolną warstwą oprogramowania. 

Przedstawiony w Algorytmach 3 i 4 sposób obsługi semaforów 
2 &wi era p ewn ą odmianę aktywnej formy czekania, polegającą na 
a Pra,wdzaniu, czy oczekiwane zdarzenie zaszło* Zasadniczym po- 
w °tiem j e j wprowadzenia była ohęć uwypuklenia identycznej roli 
8y Shałów zgłoszeń przerwań i sygnałów nadawanych rozkazem 
si Sfcal (s) dla synchronizacji prooesów* 

Ta metoda, aozkolwiek niemożliwa do przyjęcia w realizacji 
^ugramowej ze względu na czasochłonność, wydaje się opłacal- 

Przy realizacji układowej. Zauważmy, że jest ona powszeoh- 
nie stosowana (iw wielu przypadkach jedynie możliwa) przy 
°bsłudze ozęści semaforów związanych z synchronizacją proce- 
e ° w Programowych i zewnętrznych i zwana jest potocznie wykry¬ 
ciem przerwań. Rozciągnięoie jej na wszystkie semafory nie 
w >- y( iaje się ^yć kłopotliwe. 
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Pojęcie procesora wirtualnego wprowadzone zostało tu prze¬ 
de wszystkim ze względów praktyoznyoh, jako forma prostego, 
ale precyzyjnego opisu funkcji monitora z pominięciem opisu 
złożonego sposobu jego działania* 
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Ze 


C1 MXP0HH3A1PI IIPOUECCOB B BJWHCJMTMŁHOfl MAI1MHE 



Ka ochobo oómero onpeneneHHfl npouecca bbohhtch noHanw 
n P°rpaMMnpoBaHHoro npoiiecca n MOHHTopa. IlporpaMMiipoBaHHHfi 
n Poiiecc npe^cTaBjiHeT coóoił KOMÓnHamno ochobhhx npoueccoB , 
C OOTBeTCTByKDJHX KOMaH^aM nporpaMMU. MOHHTOp HBJISeTCH CHH- 
X POHH3HpyioimiM npOUecCOM flU SI nporpBMMHpOBaHHHX T/l BHemHHX 
n PoueccoB. 

Tpyjje paccMaTpuBaioTCH jiBa ajropuTMa KOMaH&Horo immia 
'■P°i;eccopa. IlepBHfi onncuBaeT mohhtop c muH ittiajtb hhm h kom- 

e KTHKM MHOHeCTBOM CHHXpOHH3HpyKmHX $yHKIQlfi. BTOpOH - OTO 
^opHTM KowiaHflHoro njiKjia BiipTyajn>Horo npoiieccopa, b naae- 
CTBe c °ÓCTBeHHoro npoiieccopa pjm Kasnoro nporpaMMupoBaHHoro 
a P°Uecca. 


Svn chronization of 


PROCESSES IN COMPUTER 



g r n ' 3ase generał definition of process the concepts of a pro- 
P rocess and monitor are introduced. A programmed process is a 
0 j ** oombination of basie processes corresponding to the instructions 
te r .' P ro gram* A monitor is a process synchronizing programmed and ex- 
r ial processes. 


SQ ^ w ° algorithms of processor cycle are presented. The first one de- 
f u ° e * the monitor with minimal and complete set of synchronizing 
aa Ct *° ns - The other one is the cycle algorithm of virtual processor 
* Private processor for each programmed process* 


°®o™ stnut Maszyn Matematycznych 
warszawa, ul. Krzywickiego 
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y j 

pracy dokonano pobieżnego przeglądu zagad¬ 
nień związanych z realizacją wieloprocesoro- 
obliczeń (programów)• Między innymi omó- 
wi °no aspekty językowe równoległości, prze- 
mi ©nność i równoległość algorytmów oraz al¬ 
gorytmy o strukturze drzewa. Więcej uwagi 
Poświęcono zagadnieniom bardziej ogólnym i 
r udniejszym pojęciowo. Zagadnienia natu- 
*7 bardziej technicznej nie zostały omó¬ 
wione. 


Spis treści 


1 . 

a. 

3. 

5. 


UWAGI WSTĘPNE 

ASPEKTY językowe wieloprocesorowości 
RÓWNOLEGŁOŚĆ i przemienność algorytmów 
ALGORYTMY o strukturze drzewa a równoległość 
UWAGI KOŃCOWE 


Łi teratura 


UWAGI WSTĘPNE 

W artykule dokonany zostanie przegląd zagadnień związanych 
2 w ieloprooesorową realizaoją obliczeń (programów) w kolejnoś- 
2 wiąza. ne j z poziomem wymaganyoh informaoji o wieloprooesoro— 
^ch obliozeniaoh i procesaoh równoległyoh. Przegląd będzie 
2 &wier a ć aspekty językowe, a następnie zagadnienia przemień- 
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nośoi i równoległośoi algorytmów, które już wymagają pewnyob 
informaoji o systemie wieloprocesorowym związanyoh ze sposoĆ 
komunikowania się z pamięoią systemu, dalej zagadnienia zwiV 
zajie z wykrywaniem równoległośoi na poziomie wyrażeń arytma" 
tycznych oraz zagadnienie określania czasu i liczby prooesoi* 
dla dowolnych obliczeń, których struktura jest reprezentować 
przez drzewo. 

W początkowej fazie stosowania maszyn cyfrowych - mimo ż* 
były one znaoznie szybsze od istniejąoyoh urządzeń mechanik 
nyoh analityozno-lioząoyoh - okazało się, że dla wielu zast^ 
sowań istniejące systemy są zbyt wolne. W związku z tym prćb* 
wano zwiększyć szybkość działania elementów podstawowych, z 
których zbudowana jest maszyna. Jednakże (mimo znaczny oh 
sów) istnieją na tej drodze dość znaczne ograniczenia naturt 
fizycznej i technologicznej. Dość wcześnie przekonano się, ** 
szybkość działania maszyn można zwiększyć również poprzez ^ 
nę struktury systemu (organizacja) i to przy mniejszym nakł*' 
dzie środków. Zmiany organizacji systemu cyfrowego oprócz 
śpieszenia wykonywania poszczególnych operacji ozy też zesp 0/ 
łów operacji polegają również na tym, że umożliwiają równooć’ 
ne (równoległe) wykonywanie poszczególnych operaoji ozy teź 
zespołów operacji. 

Przykładem, w którym uwzględniono "równoległość działań** 
są maszyny z podziałem czasu [ 7 ]* Wprawdzie trudno tu mówić 0 
pełnej równoległośoi działania programów, poza tym na pier^ 
rzut oka może się wydawać, że taki tryb pracy nie powinien ć 
wać żadnych korzyści w sensie zwiększenia szybkośoi działań*^ 1 
to jednak w praktyce okazuje się, że taki tryb pracy niejeć^ 
krotnie znacznie zwiększa szybkość wykonywania zadań ze wz(5*^ 
du na to, że pewne fragmenty programów muszą oozekiwać na ^ 
munikaoję z urządzeniami zewnętrznymi. Rzeczywistą równocze 0 
ność działania programów uzyskuje się w maszynach wieloproo^ 
sorowyoh.. 

<1 

W związku z pojawieniem się maszyn wieloprocesorowych wy y 
piło wiele problemów związanych ze strukturą systemu (arohi^ 
tura systemu) , współpraoą z pamięciami i urządzeniami peryf 0 
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fcymi, realizacją teohniozną oraz związanych z realizacją pro- 
gramów (obliozeń) • W dalszym oiągu omówiny nieco szerzej tylko 
® ru pę problemów i zagadnień związany oh z realizaoją wieloproce¬ 
sorową prooesów. 


aspekty językowe wieloprocesorowości 

Pierwszym typem zagadnień są sprawy związane z językami 
ułatwiająoymi realizaoję wieloprocesorową programów. Jedną z 
Pierwszy oh propozyoji odnosząoą się do języków programowania 
1-pJ tyło wprowadzenie : ,operaoji FORK i JOIN podająoych informa- 
°<5o, że procesy (programy) zawarte między tymi operacjami mo- 
być wykonywane równocześnie. Ogólnie mówiąc operacja FOHK 
ihiojuje równoozesne wykonanie programu bezpośrednio po niej 
Q astępują oe g 0 oraz programu wskazanego przez jej parametr, 
a °Peraoja JOIN inicjuje program wskazany przez jej parametr, 

0 ile ws^stkie programy zainicjowane przez operację FOHK zos- 
tał J zakońozone. Powyższą sytuaoję można przedstawić schematycz- 
w sposób następujący! 



Rjb. 1 

















74 


Andrzej ROWICKI 


Jeżeli ohodzi o Języki wyższego poziomu, to Jedną z pierw- 
szyoh propozycji było wprowadzenie "nawiasów Jęsykowyoh" 
PAHBEGIN i PAHEND [6], które zastosowano do programów pisanyoh 
w ALGOL-u. Jest to metoda na tyle ogólna, że może byó stosowana 
do różi^roh Jęąyków wyższego poziomu. Przykładem.tego mogą byó 
nawiasy COBEGIN i COMD [ 9 ], które zastosowano do programów 
pisany oh w Języku PASCAL [17]. Ogólnie mówiąo, wyrażenia zawar¬ 
te między tego typu nawiasami mogą byó realizowane w dowolnej 
kolejności, a więo w przypadku realizaoji wieloprocesorowej - 
równooześnie. Różnioa między tymi podejśoiami polega na tym, 
że operaoje PORĘ i JOIN zawierają pewne informaoje o sposobie 
realizaoji równoozesnej programów, natomiast nawiasy Językowe 
podają informaoje o niezależnośoi od siebie wyrażeń zawartyoh 
między tymi nawiasami. 

Innym podejśoiem do zagadnienia Jest tworzenie Języków 
uwzględniającyoh strukturę rozważanego systemu wieloprocesoro¬ 
wego. Przykładem takiego rozwiązania Jest Język algolopodobny 
TRANĄUIL [i], zaprojektowany speojalnie dla maszyny ILLIAC IV. 

W Językaoh algolopodobny oh konstrukoja POR zawiera potenojal*’ 
ne możliwośoi równoozesnego wykonywania operaoji. V praoy [8] 
zaproponowano realizaoję tego typu Języków pozwalająoą prze¬ 
kształcić konstrukoję POR na konstrukoję równoległą (PARAŁLEL 
POR). Można tego dokonać za pomooą pięoiu stosunkowo prostyoh 
funkoji PHEP, AND, ALSO, JOIN, IDLE, które zostały szozegółowo 
omówione w [8]. 

W związku z praoą wieloprocesorową powstaje zagadnienie 
uniknięoia konfliktów przy korzystaniu ze wspólnyoh zasobów, 
inaozej mówiąo, powstaje zagadnienie synohronizaoji prooesów. 
Ogólne rozwiązanie tego zagadnienia zostało podane w [6]* 

W tym rozwiązaniu posłużono się semaforami oraz operaojami P 
i V, któryoh deflnioję Czytelnik znajdzie w refera¬ 
cie T. Englerta pt. "Metody opisu synohronizaoji prooesów". 

O operaoJaoh tyoh zakłada się, że są niepodzielne i nie mo¬ 
gą być wykonywane równooześnie, Jeśli dotyczą tego samego se¬ 
mafora. 
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RÓWNOLEGŁOŚĆ I PRZEMIENNOŚÓ ALGORYTMÓW 

Jednym z bardziej ogólmy oh zagadnień jest określenie warun¬ 
ków, kiedy algorytm realizujący dany proces w sposób sekwencyj- 
może być przekształcony w algorytm realizujący dany prooes 
w sposób równoległy [a]. Rozważmy pewien algorytm A i załóżny, 
** no żony w nim wyróżnić pewne ozęśoi stanowiąoe zamkniętą oa— 
l°ść. Nieoh nimi będą algorytny A^, A 2 , Aj, A^. Załóżny, że na 
w ynik końoowy działania algorytmu A nie wpływa kolejność reali- 
Za °ji algorytmów A 2 i Aj, oo sohematyoznie przedstawiono na 
^sunku 2i 



Rys. 2 
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Algorytmy A i A' są równoważno w sensie ty oh sany oh wyników 
końoowyoh. Jeżeli algorytmy A i k* są równoważne w sensie tyoh 
samy oh wyników końoowyoh, to algorytmy Ag i A, nazywamy algo¬ 
rytmami przemiennymi. W związku z powyższym powstaje pytanie, 
ozy algorytm A" przedstawiony sohematyoznie na rys unk u 3 



fiye. 3 


jest równoważny algorytmom A i A # przedstawionym sohematyoznie 
na rys. 2, tzn. ozy przemiennośó algorytmów jest warunkiem 
dostateoznym równoległośoi algorytmów. Na pierwszy rzut oka 
wydaje się, że odpowiedź na tó pytanie powinna byó pozytywna. 
Jednakże okazuje się, że przemiennośó nie jest warunkiem dos¬ 
tateoznym ale tylko konieoznym. V przypadku gdy zaahodzi prze¬ 
miennośó algorytmów oraz wartośoi argumentów algorytmów prze¬ 
mienny oh zależą od kolejnośoi loh realizowania, to wówazas nie 
można tyoh algorytmów realizować równocześnie (równolegle). 
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Przykładem ilustrująoym niedostateoznośoi przemiennośoi jako 
w arunk u równoległośoi może być algorytm obliozania macierzy od¬ 
lotnej [12] . Przy obliozaniu maoier^ odwrotnej do macierzy M 
m °żna zastosować następująoe sekwenoje ozynnośoi: 


I 

A 

* utworzenie maoierzy prze¬ 
stawionej - M T 

* utworzenie maoierzy pod- 
wyznaozników maoierzy 
Przestawionej M* 

^ziel en j[ e elementów uzys- 
^anej maoierzy przez wy- 
z Oaoznik maoierzy M 


II 

1 # utworzenie macierzy pod- 
wyznaozników maoierzy M - M # 

2 . utworzenie maoierzy prze¬ 
stawionej podwyznaozników 
/ 

maoiersęy - M 

5. dzielenie elementów uzyska¬ 
nej macierzy przez wyznaoz- 
nik maoierzy M 


^ Powyższego przykładu wynika, że dwie różne czynności (two— 
^ ZQ nie maoierzy przestawionej i tworzenie maoier^ podwyznaoz— 
Di ków) mogą zam ienione, jednakże nie mogą być wykonywane 
^'"'nooześnie, gdyż korzystają z argumentów zależnyoh od kolej- 
wykonywania powyższyoh o^jrnności. 


^ Przedstawionego przykładu widać, że sposób korzystania 
2 ^aayoh (w naszym przykładzie reprezentowanych przez argumenty 
Miłości) ogranioza potenojedne możliwości równoległośoi 
wtąoe w algorytmaoh. 

, ^ Praoy [4] podano kryteria równoległośoi algorytmów w za- 

^thośoi od sposobu korzystania z danyoh. W oelu sformułowania 
rytem^ wyróżniny oztery zbiory zmiennych występująoyoh w 
^Sorytmie a^, mianowioiet 

W i - zbiór zmienny oh tylko pobieranyoh 
3 * X i - zbiór zmienny oh tylko pamiętanych 

* Y i ~ zbiór zmiennyoh, które są najpierw pobierane a następ- 

^ nie pamiętane 

* 2 i - zbiór zmiennych, które są najpierw pamiętane a następ¬ 

nie pobierane. 
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Jeżeli pr^rjmieny model maszyny, w któiym prooesory mogą 
się komunikować z pamięoią bezpośrednio, to warunek dostateoz- 
ny wystąpienia równoległośoi dla algorytmów A, 2 i Aj, spełnia j4” 
oyoh założenia sohematyoznie przedstawione na rys. 2 i 3, jest 
następująoy» 

X 2 n x 5 n (W 4 u y 4 ) = 0 
gdzie 0 oznaoza zbiór pusty. 

Można również pokazać, że zagadnienie wykrywania przemien- 
nośoi i równoległośoi dowolnyoh algorytmów jest nierozstrzy¬ 
galne [4J, 00 oznaoza że nie istnieje algorytm (ogólna metoda 
postępowania wspólna dla dowolnyoh algorytmów) pozwalająoy w 
skońozonej liozbie kroków dać odpowiedź, ozy rozważane algoryt" 
ny są przemienne ozy też równoległe. Powyższe zagadnienie spro" 
wadza się do problemu stopu dla maszyn Turinga, który jak wia¬ 
domo jest nierozstrzygalny. 


4. ALGORYTM! O STRUKTURZE DRZEWA A RÓWNOLEGŁOŚĆ 

Wykrywanie równoległośoi na poziomie wyrażeń arytmetyoznyob 
bazuje na znanym fakoie wzajemnej odpowiedniośoi wyrażeń aryt- 
metyoznyoh i drzew. Ogólnie mówiąo,,zasada działania tyoh alg 0 " 
rytmów [ 2 , 10, 12, 15, 16] polega na "odtworzeniu" struktury 
drzewa, odpowiadająoemu rozważanemu wyrażeniu arytmetyoznemu, 
i na ustaleniu kolejnośoi i równoozesnośoi wykonywania poszoz 0 " 
gólryoh operaoji na podstawie odtworzonej struktury drzewa. 
Niektóre z nioh bazująo na prawie łąoznośoi operaoji arytme- 
tyoznyoh [ 2 , 15 ], zmieniają tak strukturę drzewa by uzyskać 
możliwie największą liozbę operaoji wykonywany oh równooześnie* 
Wyjaśnimy nieoo bliżej tę sytuaojęt rozważmy przykładowo wyra" 
żenie arytmetyozne (((a + b) + o) - d)j korzystająo z prawa 
łąoznośoi dodawania możemy "omawiane wyrażenie przekształoić 
na następująoe wyrażenie ((a+b) + (o-d)) • Drzewa odpowiadająoe 
tym wyrażeniom są następująoe 1 
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Ze 



Rys. 4 

■ją ^^zy omawianymi algorytmami zachodzą pewne różnice. Wynika- 
ęj 0 0116 z ty oh faktów, że poszozególne algorytmy są dostosowane 
Są JSzyn o różnej architekturze, do różnych języków, w któiyoh 
0p * 8a ne wyrażenia arytmetyczne, oraz są projektowane z punk- 
15 Vl ' d2Qn:i -a pewnyoh dodatkowych własnośoi jak np.: zmniejszenia 
lub P r zeglądan" (analizowania) wyrażenia ary tire tycznego, 
proa toty kodu generowanego przez algorytm. 


z realizaoją wioloprooesorową obliczeń powstaje 

^ hienie określenia czasu i liczby procesorów potrzebnych 
^ko 

he 

* obU 


)r iania danego obliczenia. W praoaoh [li, 15 ] podano 
'■\j ^związanie tego zagadnienia dla obliczeń, których struk- 


<lr 




reprezentowana przez drzewo, a częściowe rozwiązanie 
czeń, któiyoh struktura zawiera Oklejone” fragmenty 


W bazuje się, że w drugim przypadku można również uzys¬ 
ki 0661 * 110 rozwiązanie tego zagadnienia [l4] . Ze względu na 
o g 9Q2no6 ó wprowadzenia znacznej liczby dodatkowyoh pojęć 

ril °zymy się d 0 dokładniejszego omówienia powyższego zagad- 
J]1 ie a -* 

aj -a przypadku, gdy struktura obliczenia jest reprezento- 
'.v ; . iu Pr2Q z drzewo, a poszczególne etapy obliczenia są realizo- 
^ Jednakowym ozasie. 

Ni 

**•>4 "trójka uporządkowana D =<X, P , od> oznacza drzewo, 

' ' z 1 q 
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^ — skonozony zbiór wierzohołków 
T - relaoja określona na zbiorze X 

oD- wierzchołek końcowy tzn. taki wierzohołek, że zachodzi 
następująoa relaoja f (oś)) c 0 


W zbiorze X wyróżniamy podzbiór Xp t zwany zbiorem wierzohoł' 
ków początkowyoh drzewa D t określory w sposób następująoys 

x p = {x 6X i r -1 (x) = 0 } 

Na zbiorze X określamy funkoję yj zdefiniowany w sposób 
tępująoy» 


ri{x) = 


1 jeżeli x =3 ci) 

y + 1 jeżeli V (x) a y 


Liczbę p zdefiniowaną w sposób następująoy 


P 


max 
X € X 


V w 


nazywamy rzędem drzewa D. 


Zbiór Q ^ C X określony’ w sposób następująoy i 
Qi » | x 6X t tj (x) = i| 
nazywamy i-tym piętrem drzewa D* 

Fo wprowadzeniu pojęć pomocniczych zdefiniujemy funkcje^ 
i VC f przyporządkowujące liczby całkowite drzewu D w zależ- 
nośoi od pewnyoh parametrów k i t y w sposób następujący* 
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T d>, k) 


*(», t) 

6dzt8» 
k .. 


- 

p = 


max 

ę 


i^p 

1 + i - 1 



k 



(*) 


max 

i^p 


P 

Z 

i 


fi 


t + i - i 


(**) 


w 

°kti 


^ liozba oałkowlta dodatnia 
s » > " liczba oałkowlta dodatnia większa lub równa p 
Ol - liczność zbioru Cl L 

n &dmniejsza liczba oałkowlta większa lub równa x 

f ^-Sorytm wyznaczania wartośoi funkoji H określony zależnoś- 
^ *) jest tylko nieznaozną modyfikacją algorytmu podanego 

Pl>a °y [li] , natomiast algorytm wyznaozania wartośoi funkcjiT 
a ^lony zależnośoią (■#•) został podany w praoy [l4] . 

p^lozbom T(D t k) i ‘łUD, t) można nadać określoną inter- 
ac d§ związaną z roalizaoją wieloprocesorową obliczenia. 

p Ułóżmy, że mamy dane obliozenie P, które można rozłożyć na 
1 I P 

2»* b *i ? n segmentów rozłącznych o jednakowym ozasie reali- 
Q 0 • Nleoh drzewo D reprezentuje strukturę obliczenia P' w 
® Ustępujący: między każdym wierzchołkiem drzewa D oraz 
obliczenia P istnieje wzajemnie jednoznaczne przypo- 
iwanie* jeżeli segment Pj ma być zrealizowany bezpośrednio 
m Be ® n ®noie P^ t to między wierzchołkami Xj i x^ odpowiadająoy- 
8 °gmentom Pj i P i zachodzi następująoa relaoja Xj 3 f (x Ł )#. 

przyjmiemy taką interpretaoję drzewa D f to liozba 
1 określa najmniejszą możliwą liczbę kroków (czas) f 
]* ** jest potrzebna do zrealizowania obliozenia P przy zadanej 
In ^ Procesorów równej k* Natomiast liczba ^(D, t) okreś- 
^ ^^^icjszą możliwą liczbę procesorów potrzebną do zrealizo- 
a Wliczenia P w t krokaoh. 
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5. UWAGI KOŃCOWE 

W praoy podano pobieżny przegląd pewnej ozęśoi zagadnień 
występujących przy wieloprocesorowej realizaoji programów (obi 1 * * * 5 6 7 * * 10 11 
ożeń). Prstf opracowaniu referatu kierowano się zasadą by bar¬ 
dziej szozegółowo omówić zagadnienia natury bardziej ogólnej ł 
zagadnienia trudniejsze pojęciowo. Pominięto wiel e Iważnyoh 
zagadnień występująoyoh przy realizaoji wieloprocesorowej 
gramów, ma jąoyoh oharakter bardziej teohniozny i łatwi ejszyofc 
pojęciowo. Szerszy zakres zagadnień związanyoh z realizaoją 
wieloprocesorową programów można znaleźć w praoy [?]. Natomi** 1 
zagadnienie określania czasu i liczby prooesorów dla obliczeń 
któryoh struktura jest reprezentowana przez twory bardziej 
żonę niż drzewa, zostały omówione w referaoie autora pt. f, Al^ 
rytmy określająoe liozbę prooesorów oraz ozas trwania oblioz 0 " 
nia". 
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HEKOTOPUE ACIffiKTŁl MHOrOIIPOUECCOPHhK BŁTO1CJIEHM 


Pe3EMe 


B Tpy,ne flaH odmuft od 3 op npodJieM, cbh 38 hhhx c ocymecTBae- 
HH 6 M MHOrOnpOU,eCCOpHHX BHHHCJieHHtt (npOrpaMM) . B HaCTHOCTH 
onncaHK 'H 3 ukobu@ acneKTu napajuiejni 3 Ma, KOMMyTaTMBHOCTL a 
napajuiejiŁHOCTŁ ajiropiiTMOB u ajiropHTMH, UMemmue CTpyKTypy 
flepeBa. 

Ocodoe BHHMaime yaejieHO dojiee odmuM npodJieMaM, CBH 3 aHHHJ< 
c BBeaemieM noHamfi. BonpocH TexiciHecKoro xapaKTepa He 3a- 
TparHBaiOTCH. 


SBLBCTED ASPECTS OF MULTIPROCESSING 


Summary 


This paper presents a brief survey of problems on raultiprocessor 
realization of computations (programs). 

There are considered, among others, lingual aspects of paranoi***' 
commutativity and parałlelism of algorithms and treo structure alg0" 
rithms. 

Attontion is paid to generał and notionalły difficult ąuestiona 
rather than to probłems of a technicał naturę. 
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Pracy 


U* ^ odano dwa algorytmy pozwalające oszaco- 
procesorów i czas trwania obliczenia. 
kt6 r " &Ze algorytmy są poprawne dla obliczeń, 
ci e Q n * e zawierają pętli oraz mają jedno wyjś- 


w 


związku z realizaoją wieloprocesorową obliczeń powstaje 
^^^ńienie określenia ozasu i liozby prooesorów potrzebny oh 
^konania danego obliozenia. Ten problem został częściowo 
2w i^zany w publikaojaoh [i, 2], mianowioie w pracy [i] poda- 
a lgoiytm wyznaozania liozby prooesorów potrzebnyoh do wyko- 
l^ńia obliozenia dla zadanego ozasu (liozby kroków), w przypad¬ 
ły struktura obliczenia jest reprezentowana przez drzewo. 

^ °ffiiast w [ 2 ] podano algorytm wyznaozania liozby prooesorów 
a Najkrótszego możliwego ozasu (najmniejszej liozby kroków) 
^^Hzaoji obliozenia, w przypadku gdy struktura obliozenia 
^ Sprezentowana przez dowolny graf nie zawierająoy pętli. 
Draoy przedstawiny dwa algoiytny pozwalająoe oszaoowaó ozas 

i ] j 

1Q zbę prooesorów potrzebnyoh do wykonania obliozenia nie 
^■srającego pętli, a mianowicie i 


algorytm określająoy ozas wykonania obliozenia przy z góiy 
2 adanej liczbie prooesorów k f 

algorytm określający liozbę prooesorów potrzebną do wykona- 
obliozenia w z góry zadanym ozasie t* 
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Powyższe algorytmy opiszemy dla modelu obliczenia reprezen¬ 
towanego przez graf zorientowany. W oelu uniknięoia nie jasnot 
przypomnimy podstawowe pojęoia z teorii grafów oraz zdefiniuj® 1 * 
pewne dodatkowe pojęcia potrzebne do opisu algoiytmów. 

Bozważmy następujący graf G = < I, T , uo > , gdzie* 

X - jest skońozonym zbiorem wierzchołków 
T ■» jest relaoją zdefiniowaną na zbiorze X 

cO - jest pewnym wyróżnionym wierzohołkiem zwanym wierzchołki® 11 
końoowym grafu G, tzn. takim wierzchołkiem, że zaohodzi 
następująoa relaoja T (co) = 0 (gdzie 0 oznaoza zbiór pus¬ 
ty ) 

Jeżeli między wierzohołkami x i i x.j zaohodzi relaoja 

' Xl 6 r(x.) , to"sytuaoję tę interpretujemy w sposób następuj^' 
d * 1 

oy 



Rya« 1 

Parę wierzohołków u i = <x it x^> nazywamy łukiem, je¬ 
żeli zachodzą następująoe relaoje* x^€r(x^) oraz x i ^r(x^)* 
Natomiast parę wierzohołków w^ = <Xy x'> nazywamy krewę- 
dzią, jeżeli zaohodzą następująoe relaoje x j £ ^( x j) lub 
Xj € r(Xj)• 

Ciąg łuków U/, i • • « « u it .. u k nazywamy drogą, jeżeli 

zachodzą następująoe relaoje x^ 4 x^ oraz dla każdego 
1 ^ i < k, x , i = x i+1 . Jeżeli zamiast relaoji x^ 4 x Jc zaohodz- 
relaoja = x k , to ciąg łuków u^,..., u^,..., u k nazywamy 

p 

Ciąg krawędzi w.j,..., w^,... f w k nazywamy łańouohem, j 0 ^ 
li zachodzi następująca relaoja / x^ oraz dla każdego 
1 <i4k, = x i+1 . Jeżeli zamiast relaoji x ± / x k zaohodzi 

relaoja x ± = x k , to oiąg krawędzi w 1 ,..., w^..., w k nazywać 
obwodem. 

Graf G = < X, P, > nazywamy sieoią, jeżeli 
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n ^ e zawiera pętli 

<U a każdego wierzchołka x ^ aO istnieje droga do wiorzohoł- 
końcowego co . 

Natomiast sieć G = < X,P , <*> > będziemy nazywali drzewem, 
nie zawiera ona obwodów. 

" ^alszyoh rozważaniaoh ograniczymy się tylko do sieci. 


Zbió: 


Hd 


r XpCZ ^ zdefiniowany w sposób następujący 

V H 1 ' r - 1 ( *> = 0) 


Uc 


2 ie% nazywali zbiorem wierzchołków początkowych sieci G. 

^atomi as t zbiór S cz X zdefiniowany w sposób następujący 

0 = {x 6 X: rt*) > i) 

Jioi ay nazywali zbiorem rozgałęzień sieci G, gdzie X oznacza 


2 hoóć zbioru X. Łatwo się przekonać, że jeżeli G = 0, to 
8 ieć r j 

■ Jest drzewem. 

x * a zbiorze X określimy dwie pomoonicze funkcje § i y zwane 
dietami. Funkcje ^ i i? definiujemy w sposób następujący 


* 1 *) * 
li 


1 jeżeli x sc«D 

{ I (7) } + 1 jeżeli y £ T " 1 (x) 
y 6 (x) 

9 zdefiniowaną w sposób następująoy 


ba 


r, = max 
K XfiX 


[iw 


raędem sie0 i q. 

1 ? (x) = p + 1 - !(x) 

łatwo zauważyć, że zaohodzi następująca zależność 


max (x) 
P " x 6 X 


^fcuł em p rZ yjcładu rozważmy sieć przedstawioną na rysunku 2. 
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Dla sieol przedstawionej na rys. 2 uzyskujeny 

a • 

Xp - {a, b) 

9 = {oj 



Natomiast wartośoi funkcji i? i ę są przedstawione w P 0 ” 
szej tabeloe 


Tabela 1 



a 

b 

0 

d 

e 

? 

4 

3 

3 

2 

i 

1 

i 

2 

2 

. 3 

4 


Na mooy tabeli 1 uzyskujemy, że 

p = 4 

Na podstawie funkcji zdefiniujmy teraz zbiór * 
sób następujący! 

n i a ( x€xi A 

Zbiór nazywamy i-tym poziomem sieoi G. 

j' 

Do zdefiniowania funkcji f i , odgrywających zased 
czą rolę w naszych rozwaźaniaoh, będą potrzebne jeszoze P e 
funkcje pomoonioze V i yT . Funkoje i) i definiujemy * 
sposób następujący! 
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•0(1) 


*1. 


największe takie j < i, że jj 

O w przeciwnym przypadku 


k) = 


n 

2 ' li, 

•*LA1-±1- 1 + i - n 

k 


max 

•ł(±)< n<i 

"- lo k jest liozbą oałkowitą dodatnią, a |"x| oznaoza naj- 
e dszą liozbę oałkowitą większą lub równą x. 

^oraz przystąpimy do podania definioji funkoji <p i T • 

^ofinioja 


2 ° 


?(0, k) = O 


*(i+1, k) 


TC i, k) + Q 1+1 jeżeli Q 1+1 0 9 = 0 
„ <f>(-J(i+1) ,k) + k • >Jti+1,k) jeżeli g 1+1 n9^Cf 


^ W Przypadku gdy 9= 0, oo oznaoza, że rozpatrywana sieć jest 
2 ® w em, można pokazać, że 

Z 


¥(i, k) 


«j 


^finiojjay p 

l0 Z TL 

' 'Pd.n.tj 3 


2 ° 


\i>, ^(P” i»r^fd* p(i)ł t)i) 

Y(1+ 1,0,t) = ——- 


t - i 


3° w. „ «p(p - h>(i+1, n, t;1) 

' l+ 1» n+1, t) = ——- 

t - i 

Sdzi 

P (i) oznaoza najmniejsze takie n, 
lv P(i, n, t)l * hp(i, n+1, t)l 

« jest liozbą oałkowitą dodatnią spełniająoą następująoą 
ne iność t >p 
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Kontem obliozenia F istnieje wzajemnie jednoznaozne prżyporz^' 
kowanie; przyporządkowanie to jest takie, że jeżeli segment Pj 
ma być zrealizowany bezpośrednio po segmenoie F^, to między 
wierzohołkami x^ i x^ sieoi G odpowiadająoymi segmentom F^ 1 
P 1 obliozenia F zachodzi następująoa relaoja x^ = T (x Ł ). 

Można pokazać [j], że dla tak pr^rjętej interpretaoji zaoh 0 ' 
dzą następująoe twierdzenia. 

Twierdzenie 1 

Nieoh T (G, k) oznaoza liozbę kroków (jednostek ozasu) P 0 “ 
trzebną do zrealizowania obliozenia P przy zadanej liozbie P r<r 
oesorów równej k, a T*(G, k) funkoję określoną zależności^' 
to wówozas 

T (G, k) > T (G, k) >Tr H (G, k) 

Twierdzenie 2 

Kie oh G(n) oznaoza sieć zawierająoą n wierzohołków, to wóW" 
ozas dla dowolnego n i dowolnego k istnieją takie sieoi G^(^ 
i Gj (n), że 

T (G^n), k) ■ T (G^n), k) oraz 
T (Gj(n) , k) ='t K (G ;j (n), k) 

Twierdzenie 3 

Nieoh £ (G f t) oznaoza liozbę procesorów potrzebną do 
lizowania obliozenia P w czasie t (w t krokaoh) 9 a % (G, 

funkoję określoną zależnością (•# *) v to wówozas 

1*(G V t) > K (G, t) >.tt*(G, t) 


Twierdzenie 4 

Nieoh p (n) oznaoza rząd sieoi G(n), to wówozas dla dowol 
nego n i dowolnego t > p(n) istnieją takie sieoi G^n) i 
Gj(n), że 
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^dą 


& (G^(n), t) = 3t(G^(n), t) oraz 
K (Gj(n), t) = tt*(G.(n), t) 

7 

twierdzeń 1 i 3 oraz z zależności (•*) i (* ■#) wyni- 
^astępująoe twierdzenia 


Twi 


gżenie 5 

^ e żeli sieć G Jest drzewem, to 


1 (G. 


k) 


max 

1< i<p 


p+1-i 

Z £2, 

i J 


+ i - 1 


T (G, k) Jest najmniejszą możliwą liozbą kroków 
■bostek czasu) potrzebną do zrealizowania obliczenia P przy 
o liczbie procesorów równej k. 



2Q li sieć G Jest drzewem, to 


(G. 




t) = 


max 

1< i< p 


p +1-i 

E Q. 

1 3 

t + 1 - i 


*) 


■''^■ G zba. K (G, t) Jest najmniejszą możliwą liczbą prooesorów 
^bną zrealizowania obliczenia w czasie t (w t krokach). 




C0 lu zilustrowania wprowadzonyoh pojęć i algorytmów oraz 
i G Wieri:1 - a wyrobienia intuioji rozpatrzymy trzy sieci G^, G ? 
^ 3* które sohematyoznie przedstawiono na rys. 3. Sieoi te 
dsdnakowy rząd i zawierają jednakową liozbę wierzohołków 


^Ją identyozną liozbę wierzchołków na poziomaoh. 


D ia 


a sieci przedstawionyoh na rys. 3 uzyskujentf 

B *3 = b * °» d * 6 ’ f ’ S * h ’ ^ 



2 = 


Q 2 = t 9 } 9 3 = { b * °» d * 

ten jest nieznaną modyfikacją algorytmu podanego w [i]. 














m 

► 
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Wartości funkoji ( i ł) dla sieoi G^, G 2 , G^ są identyozne 
* P°^ane w następującej tabeloei 


Tabela 2 



a 

b 

0 

d 

e 

f 

e 

h 

k 


5 

4 

3 

3 

3 

2 

2 

2 

1 

l 1 .2,3 

1 

2 

3 

3 

3 

4 

4 

4 

5 


N a mooy tabeli 2 uzyskujemy, że 

P = 5 oraz 
O 


O 


* W 

o 2 3 ^ 

q 3 = (o, d » e} 

a = {f, g, h} 

°5 - (1=} 

^ałóżry, że do dyspozyoji mary dwa prooesory, tzn.żo para- 
k a 2 . Dla tej wartośoi parametru wyznaozamy wartość funk- 
^ 'P dla sieoi G^. 

Na mooy definioji funkoji «P uzyskujemy 

(0,2) = O 


tom, 


ew aż G o © = 0 to 


Pom 


f 5 (1,2) = ^(0,2) + &,, = 1 


ew aż ? 5 2 ney 0 to 


mo 


cp 5 (2,2) = <P 3 (^(2), 2) + 2 • tf(2,2) 

°y definioji funkcji uzyskujemy ^(2) = O, a więó 
2 




max 

[ę s j 1 




i 



-S- + i - n 


3 

max < 

1 , 1,5 


0 < n <2 

2 




b 
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Ponieważ <£3 (•$( 1 ) t 2 ) = O, to uzyskujemy ostateoznie 

( 2 , 2 ) = 4 

Ponieważ G^n 0 4 0, to 

( 3 , 2 ) * <? 3 . k) + 2 • *( 3 , 2 ) 

Ponieważ "tf(3) * 2, to 


<f ? (*(3) , k) « 4 


oraz 


■^(3,2) 



3 _ 


max 

g^j 



—-- + i - n 


2<n<3 

2 



a więo uzyskujemy ostateoznie 


<? 3 ( 3 , 2 ) = 8 

Ponieważ ■ 0 oraz 0^0 0 ■ 0 to 

Spj (*.2) - <P 5 ( 3 . 2 ) ♦ ^4 - 11 
<?3 (5,2) o qp 5 (4,2) + Ó 5 » 12 


Postępująo w podobny sposób wyznaozamy wartośoi funkoji 
dla sieoi i Gg. Dla k ■ 2 uzyskane wyniki zestawiono * P 
niższej tabeloe 

TabelfJ 


i 

1 

2 

3 

4 

5_ 

*1 

1 

2 

5 

8 

9 

*2 

1 

2 

6 

9 

10 

*3 

1 

4 

8 

11 

12 

—0* 


Teraz przystąpimy do wyznaozania liozby kroków potrzebni 

• pO * 9 

do zrealizowania obliczeń, któryoh struktura jest reprezen v 

na przez sieoi G^, Gg i Gj. 
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Ze 


Ponieważ sieć jest drzewem (0.^ = 0 ), to na mocy twier¬ 
dzenia 5 i tabelki 3 uzyskujemy: 



Natomiast na mooy tabelki 3 funkcja X dla sieci G 2 i G^ ma 
Ostępujące wartości: 


T'(G 2 , 2) = [" max 
T(Gj, 2 ) = |"max 




Na mooy twierdzenia 1 uzyskujemy ostatecznie 

6> T (G 2 , 2) > 5 
7 > T (Gj, 2) > 5 

Na rysunku 3 pokazano, że rzeczywiście można zrealizować 
^liczenia, których struktura jest reprezentowana przez sieci 

Q 

1 * w liczbie kroków określonej rozważanymi algorytma- 

^9 oraz łatwo się przekonać na podstawie rys, 3 f że nie moż- 
^ zrealizować obliczeń w mniejszej liczbie kroków, Najmniej- 
S2e możliwe liczby kroków dla sieci G^, G^, G^ są następujące: 

5 * 5 , 7 , 

Rozważymy teraz zagadnienie odwrotne do poprzedniego, a mia- 
h ° w icie dla zadanego czasu realizacji (liczby kroków) oblicze- 
wyznaozymy potrzebną liczbę procesorów. Wyliczeń dokonamy 
^Iko dla sieci G, i dla następującej liczby kroków: 5, 6, ?• 

Nla t = 5 na mooy definioji funkoji f uzyskujemy: 

Y(1, n, 5) = ~ oraz 

5 

Y(1, p CD. 5) = 2 
5 

Przystąpimy teraz do wyznaczania wartości funkoji Y d l a 
1 = 2 








96 


Andrzej BOWICKI 


¥(2,0,5) 


¥(». Ul) 


Na mooy rozważań z poprzedniego przypadku uzyskujemy, że 
^(4,2) - 11, a wlęo 


¥(2,0,5) » H 


¥(2,1,5) 


¥(4, [ Ą\) ¥(»,3) 


Przystąpimy tsraz do wyznaozenia wartości funkoji|¥ dla 
i - 4 i k ■ 3* 


Ponieważ Q^n 

e . 0 

to 

¥(4,3) - 

¥(5,5) + 

-¥(3,3) + 3 

Ponieważ 0 ? n© 4 0 oraz -9(3) » 2 , to 

¥(3,3) - 

¥(2,3) 

+ 3*-O 1 (3,3) oraz 

tf(3,3) » 


n 

ę .. 

2<ń£3 

3 J 

stąd 



¥(3,3) - 

¥(2,3) 

+ 3 


Ponieważ Clg 0 ®^ ^ ora * ( 2 ) a °» to 

¥(2,3) “ ¥(0,3) + 3 * tf(2,3) oraz 


•W.2,3) 


max 

0<n<2 


E 5;, 

_3_ t 2 - n 


■ max 


2 , t 

3 3 
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a więo 

9(2,3) = 6 

Na podstawie przeprowadzonyoh obliozeń uzyskujemy ostateoz- 

ttie 


9(^,3) a 12 a więo 
9(2,1,5) * 3 

Ponieważ 9 ( 2 ,0,5) = — oraz 9(2,1,5) = 3 to 

4 

9(2, (i (2), 5) = — 

4 

Wyznaozymy teraz wartość funkoji 9 dla i = 3 

9 ( 3 . [- 41 > 9 ( 3 . 3 ) 

9(3,0,5) = —- L - iLL = -- 

3 3 

Na mooy poprzednioh rozważań uzyskujemy 


9(3,3) » 9 a więo 

9(3,0,5) » 3 


9(3,1,5) 


9(3, f3]) 
3 


00 daje ostateoznie 


= 3 


9(3, p(3), 5) = 3 

9(2, T3l) 

9(4,0,5) = --- 


Na mooy poprzednioh rozważań 9(2,3) = 6 a więo 


9 (^. 0 , 5 ) » 3 

9(4,1 ,5) a 


9( 2 » fcl) 

2 


= 3 


00 daje ostateoznie 
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Y(4. ji (4), 5) = 3 
V (5,0,5) = 5 ( 1 , r 3l) 

Ponieważ O 9 = {( to ,V(1, 5) = 1 a więc 

Y(5,0,5) = 1 
*(5,1,5) = &(1, N) 

Ponieważ *(1,1) =1 to 

Y(5, p (5), 5) = 1 

Postępująo podobnie jak dla t = 5 wyznaozany wartośoi funfc' 
cji \> dla t = 6 i t = 7* Uzyskane wyniki są podane w poniż' 
szej tabelce 

Tabela 4 


i 

1 

2 

3 

4 

5 

Y(i, H (i), 5) 

| 

11 

"5 

3 

3 

1 

Y(i, jj(i) , 6) 


11 

3 

1 

2 

1 

5 

Y(i, p(i), 7) 


11 

~Z 

8 

5 

1 

| 


Na mocy definicji funkcji * oraz tabeli 4 uzyskujemys 


*(G y 5) 
«(G 5 , 6) 
Wy 7) 


r 

f . 9 

11 

1 max 

I 1 ’ 5 

* T • 

r 

r 1 9 

11 

| max 

U • * 

, 3 , 

r r 

1 

9 8 

| max j 

1 , 1 

7 ' 5 * 



Natomiast wartość funkcji V* wyznaczamy na podstawie 
ności (* *) 


zal^ 
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(Gy 6 ) 

7) 


f max 

I 1 2 5 9 8' 

| 5 • 1 ’ t • t • 5 

r 1 

fi 1 -.3 8 I 

| max j 

l? ’ 5 * n ’ 7 ’ SJ 


2 

2 


Na rnooy twierdzenia 3 uraz na podstawie uzyskany oh wyników 

tr zymujemy ostateozniei 


3 > K (G ?ł 5) > 2 

3 > K (G 5 , 6) > 2 

2 > K (G ? , 7) > 2 

Na podstawie rysunku 3 można się przekonać, że obliczenia, 
k t a ^ 

' '°**ago struktura jest reprezentowana przez sieć G^, nie można 

liczbie procesorów mniejszej od 3 zrealizować w 5 lub 6 

^ r °kach f natomiast dwoma procesorami można go zrealizować w 

*^ Q zbia kroków nie mniejszej niż 7» co jest zgodne z wynikiem 

Uz y8kanym na podstawie twierdzenia 3 oraz niesprzeczne z wyni¬ 
ki 

em Uzyskanym na podstawie twierdzenia 1. 


J HU T f C.i Parallel Seąuencing and Asserably Linę Problems Operations 
Research, 1961 , vol. 9# nr 6, s. 841-848. 

2 J RAMAMOORTHY C.V., CHANDY K.M., GONZALES M.J.: Optimal Scheduling 
Strategies in a Multiprocessor Systems, IEEE Trans, un Comp., 

^ 1972, vol. C-21, nr 2, s. 137-146. 

J H0WICKI A.: Związki między czasem realizacji obliczenia a liczbą 
procesorów (w przygotowaniu). 
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Peanie 
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onpeA&iHTB hiojio nponeooopoB a Bpe»w BiroiojieHHa. IIpeaoTaB- 
jieHHue ajiropBTMU npaBJULHH juir Bmnojiemift o oahuu błdcosom 
a He coAepsammc newielł. 


ALOORITHMS ESTIMATIHG NtfoBER OF PROCESSORS AND DURATION O F COKPUTATIOS 


Sumary 

This papar praaants two algorithns for tha astiaation of tha miaba* 1 
of prooassors and for tha astiaation of tha ooaputatlon duration. Tha 
algorithas ara proiran for oomputatlons contalnlng no olroults and onU 
ona output* 
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MODELOWANIE I EKSPERYMENT SYMULACYJNY 

W PRO JEKTO'W ANIU SYSTEMÓW CYFROWYCH 

Piotr BIELKOWICZ 
Piotr PERKOWSKI 

Instytut Maszyn Matematycznych 

Pracę złożono 10.1 .1974 


»ir 0st 

v Jch zł °ioności współczesnych systemów cyfro¬ 
wych* Wifnik ający z rozwoju możliwości funkcjonał¬ 
em 8T) 6 ^ rz ^^ u » w ys°kie wymagania użytkowe dotyczą- 
t6w ,]£ awno ^ c * oprogramowania, zmuszają projektan- 
° sz ®rokiego korzystania i rozwijania narzę- 
c Ję J^&ramowych umożliwiających szybką weryfika- 
. ocenę ilościową koncepcji projektowych. 

r *yk\T 

się w 1 Porusza istotne problemy, które wyłaniają 
Poqj 0 Cz asie projektowania złożonych systemów za 
bl Qn} ^ m odelowania symulacyjnego. Omawiane pro- 
Poparto przykładami praktycznymi. 


Spis treści 

2 t> 0 f>fi AWNOŚ 6 MODELU 

3 PROb LEMY ZWIĄZANE Z PROJEKTOWANIEM EKSPERYMENTU SYMULACYJNEGO 

4 2 BlE ^N0Sć STOCHASTYCZNA 

s ^ R2y KŁADY 

6 PEWNe ASPEKTY OPTYMALIZACJI PROJEKTOWANYCH SYSTEMÓW 
L ‘ 2 AK 0 «CZEN IE 
tst nura 
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WST^P 

W niniejszej pracy rozpatrujenęr problemy związane z wykof^ 
staniem teohniki symulacyjnej w projektowaniu i optymalizaoj* 
złożonych systemów cyfrowych. Mówiąc o optymalizacji (minin^ 1 
zacjl lub maksymalizacji wybranyoh parametrów systemu dla 8 ^' 
nów ustalony oh) przyjmujemy, że smagania użytkowe oraz kry te ' 
ria ooeny charakterystyk użytkowych projektowanego systemu 
zostały uprzednio sformułowane. 


Możliwo są dwa podejścia do problemu projektowania systo^ 


1. poszukiwanie rozwiązania dopuszczalnego, tj. spełniająoefi 0 
zbiór wymagań (ograniczeń) , 


2. poszukiwanie rozwiązania optymalnego, tj. najlepszego, * * 
sie przyjętego kryterium oceny, spośród rozwiązań dopusZ 0 *' 
nyoh (np. maksymalna przepustowość systemu przekazywania ^ 
dunków, minimalny czas odpowiedzi systemu wyszukiwania & 
formacji, maksymalna liczba urządzeń końoowyoh w systowi 0 
wielodostępnym). 


Wymienione wyżej problemy, rozpatrywano w fazie projekt 0 ^ 
systemu, wymagają posługiwania się modelem zastępującym rz efli * 
wisty obiekt i umożliwiającym oszacowanie charakterystyk 
wych systemu. Najbardziej pożądanym typem modelu jest zawsZ 0 
pełny model analityczny. Zwykle jednak, w przypadku syste» ÓW 
złożonej, niejednorodnej strukturze, dużej liczbie zmienny 0 * 1 
ozy nieliniowyoh zależnościach między zmiennymi konstrukcji 
praktyoznie użyteoznego modelu analitycznego jest niemożli^ 
lub nieopłacalna. W tej sytuacji jedynym dostępnym, ekonom^ 

o> 

uzasadnioi^m postępowaniem jest budowa modeli symulacyjny 
eksperymentowanie z tymi modelami. 


Podstawowymi problemami pojawiającymi się na etapie 
modelu są weryfikacja poprawności modelu i minimalizaoja ' 


Może się zdarzyć, że w trakcie budowy modelu pominięte 
ną zmienne i relacje między tymi zmiennymi istotne dla no 
nego systemu. Możemy również popełnić błędy w modelowaniu 


y 
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systemu. W takim wypadku model nie jest poprawny, tzn. ża¬ 
łowanie się modelu dla danego strumienia danyoh wejściowyoh 
°dbieg a znacznie od zachowania się rzeczywistego systemu. Oczy¬ 
śćcie nie można oozekiwać, że zachowanie się modelu będzie 
identyozne jak obiektu rzeozywistego. Rozbieżność powinna jed— 
r >ak mieścić się w raojonalnych granioaoh. Niepoprawny model 
dest oozywiśoie bezużyteczny. Jednym ze sposobów "polepszenia” 
m °delu jest zwiększenie jego szczegółowości. Wiąże się to jed- 
n ak ze wzrostem kosztów symulaoji i analizy wyników. 

Zwiększanie szczegółowości modelu kłóci się z dążeniem do 
śnimaiizjacji modelu. Minimalizaoja postuluje uwzględnienie 
tylko najistotniejszych zmiennyoh i relacji. 

Problemom poprawności i minimalizaoji modelu poświęcone są 
par> agrafy 115. Mająo model systemu i przystępując do ekspery- 
® er it;6w na maszynie cyfrowej, należy wiele uwagi poświęcić właś— 
Śwemu loh zaprojektowaniu. Celem każdego eksperymentu jest po¬ 
gnębienie wiedzy o badanym systemie, w szozególnośoi o związ¬ 
ał między zmiennymi uwzględnionymi w modelu, zależnośoiaoh 
śędzy odpowiedzią (kryterium oceny) systemu a zmiennymi kon¬ 
trolowanymi itp. Informaoje te należy zdobyć minimalnymi kosz- 
dlatego też projekt eksperymentu powinien uwzględniać pro¬ 
blematykę zbieżności stochastycznej, doboru długośoi próbki itp. 

Podstawowym problemom projektowania eksperymentu symulacyj¬ 
no poświęcony jest paragraf 2. W paragrafie 3 omawia się 
z bieżność stochastyczną i związane z nią problemy weryfikaoji 
lulków symulaoji i doboru długośoi próbki. 

W paragrafie 4 omówione są dwa przykładowe problemy, któro 
w d osyć prosty sposób mogą być rozwiązane za pomocą modelowa- 
symulaoyjnogo. W paragrafie 5 podkreślono najistotniejsze 
a Prawy związane z symulowaniem powyższy oh przykładów. 


1 ’ POPRAWNOŚĆ MODELU 

^oryfikaoja poprawności modelu jest jednym z najistotniej- 
8 *»oh problemów z Jakimi spotykamy się w naszych rozważaniach 
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Wiąże się ona z wieloma zagadnieniami natury praktycznej teore" 
tycznej statystycznej i nawet filozoficznej. 

Najłatwiej jest weryfikować model w przypadku, gdy wyniki 
otrzymane z symulaoji mogą być bezpośrednio porównywane z daitf - ' 
mi pochodzącymi z systemu rzeozywistego* Jeżeli rozbieżności 
nie mieszczą się w dopuszczalnych granioaoh, model jest modyfi" 
kowany. Sytuacja komplikuje się, jeżeli nie mamy możliwości 
oparcia się na obiekcie rzeozywistym, tzn. wtedy, gdy system 
rzeczywisty jest dopiero projektowały. W przypadku, gdy system 
projektowany jest zbliżony do systemów istniejących, poprawność 
modelu możemy stwierdzić porównując go z tymi systemami. Nale^ 
jednak zachować ostrożność przy wyciąganiu wniosków, pamiętaj^ 0 
o różnicach między systemem projektowanym a istniejącymi. 

/ * A' 

Sytuacja pogarsza się jeżeli dis. projektowanego systemu tr 0 
no znaleźć analogiozny przypadek. 

Proponuje się rozbicie modelu na podmodele o różnych stop¬ 
niach szczegółowości. Na przykład model z grubsza opisujący 
działanie oałego systemu może być prosty i zawierać mało zmie 11 ^ 
nyoh i relacji. Z drugiej strony model użyty do analizy algo*!' 
mu przydziału wybranej jednostki pamięoi dyskowej powinien by 15 
bardziej szczegółowy. 

Rozbioie powinno iść w tym kierunku, aby sprawdzenie popra^ 
ności "najniższych" podmodeli było już proste (np. podmodel 
przydziału pewnego urządzenia można porównywać ze znanymi 
laml analitycznymi lub anałogioznymi rozwiązaniami dla inny° b 
istniejąoyoh systemów) . Oozywiście z poprawności podmodeli 
wynika poprawność oałego modelu. Wnioskowanie o poprawnośoi 
całego modelu będzie opierać się przede wszystkim na intuicj* 
projektanta. Powyższe zagadnienia omówione są szerzej w [ 5 ] 
oraz w [ 9] i fio) . 

2. PROBLEM! ZWIĄZANE Z PROJEKTOWANIEM EKSPERYMENTU SYMULACYJ" 

NEGO 

Należy zauważyć, że model symulaoyjny jak każdy model ni 0 
powinien być rozpatrywany w oderwaniu od oelów, którym służ! 
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sam model nie uzupełniony odpowiednim projektem eksperymentu 
®°że być rozpatrywany jedynie jako narzędzie opisu rzeozywiste- 
8° obiektu. Upraszozająo zagadnienie można przyjąć, że podsta- 
w °We problemy projektowania eksperymentu związane są z poszu¬ 
kiwaniem odpowiedzi na następujące pytania [ą]: 

/i 

% Czy dany czynnik (zmienna niezależna, wejściowa) jest kon¬ 
trolo walny ? 

Cżyroiik uważamy za kontrolowalny wtedy, jeżeli jego wartośoi 
być ustalone w ozasie eksperymentu w sposób zamierzony, 
zgodny z określoną regułą decyzyjną. 

* Czy dany czynnik jest obserwowalny? 

Czynnik uważamy za obserwowalny jeśli jego wartości mogą 
być obserwowane lub mierzone i rejestrowane jako część da- 
ryoh. W eksperymentach symulacyjnych z natury rzeczy mamy 
ćo czynienia z czy nn ikami kontrolowalnymi i ob serwo walny mi. 

Czy dany czynnik jest czynnikiem podstawowym czy też pomoo- 
hiczym zwiększającym jedynie dokładność eksperymentu? 

* Czy dany czynnik ma oharakter ilościowy czy też jakościowy? 
^zykładem czynnika o charakterze jakościowym może być np. 
Sienna decyzyjna, wyrażająca pewną regułę decyzyjną. 

Czy dany ozynnik ma oharakter przypadkowy? 

Ni e zmiemie istotnym problemem z punktu widzenia projektowa— 
sksperymentu jest określenie oelu eksperymentu, którym mo- 

być 

I 

* 0 Ptymaiizaoja, tzn. znalezienie takich wartośoi czynników, 

których odpowiedź systemu (modelu) osiąga ekstremum 
b 

r °zpoznanie oharakteru zależności odpowiedzi systemu od 

Cz ynników. 

J °cłną z metod znalezienia ekstremum odpowiedzi systemu 
^ p rzyp adku dennych dyskretnych, decyzyjnych jest zbadanie 
^ 2ya tkich możliwyoh kombinaoji zmiennych, tzn. pełny ekspe 
ia ht. ^ odniesieniu do zmiennych o charakterze ciągłym 
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(ilośoiowym) problem jest znacznie prostszy i możliwe jest ster 
sowanie rn.in, metod programowania matematycznego [5]» 

W tym wstępnym, pobieżnym przeglądzie problematyki projekto" 
wania eksperymentów należy jeszcze wspomnieć o zagadnieniu mini'' 
malizaoji modelu, tzn. redukoji liozby ozynników i doborze dłu" 
gośoi próbki, Do problemów tyoh powrócimy w następnych paragi®' 
fach. 


3. ZBIEŻNOŚĆ STOCHASKCZNA 

Większość badanyoh prooesów w rozważanej przez nas klasie 
problemów ma oharakter stochastyczny. W wyniku eksperymentów 
symulaoyjnyoh otrzymujemy żądane ooeny statystyozne tych proce' 
sów w postaci wartości średnich i warianoji. 

Wszystkie estymaty poszukiwanyoh wartośoi średnich oblicza" 
ne są na podstawie próbek o skończonej liczności, uzyskiwanych 
z kilku przebiegów symulaoyjnych. Zwiększenie dokładnośoi es ty" 
macji, tzn, zwiększenie prawdopodobieństwa, że wy znaczone śreń' 
nie będą bliższe rzeczywistym średnim, jest możliwe przez 
zwiększenie długości próbki. Miarą przypadkowyoh fluktuacji 
wielkośoi losowej jest jej odohylenie standardowe. Pamiętaj^ 0 * 
że estymata wartośoi średniej populaoji jest samą zmienną los#* 
wą, można przyjąć jako miarę dokładnośoi ooen statystycznych 
wyznaozonyoh w ozasie prooesu symulaoji, odohylenie standardo" 
we estymaty wartośoi średniej ó rr • W przypadku n statystyce 
nie niezależnyoh obserwaoji 

A -L- 
x 3 Y5 

gdzie 6 jest odohyleniem standardowym pojedynozej obserwa" 
oji (próbki) 

Zatem aby dwukrotnie zmniejszyć przypadkowy błąd jakim oba 1 ^ 
ozone są wyznaozone wartośoi średnie (np. średni ozas oczeki*'* 
nia w kolejoe, średni ozas odpowiedzi itp.) należy ozterokr 
nie zwiększyć długość próbki n (tak więo tę samą kolejkę n® 16 
ży obserwować ozterokrotnie dłużej). 
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W efekoie utrzymywanie błędów na rozsądnie niskim poziomie 
być związane z dużymi kosztami. 

Taki stan rzeczy skłania do poszukiwania innych metod reduk- 
°dl błędów. Na przykład można posługiwać się metodami Monte 
Carlo w oełu zwiększenia efektywności eksperymentów symulaoyj- 
Zasadą łeżąoą u podstaw techniki Monte Carlo jest pełne 
'"ykorzya-fcanfb informacji dotyoząoyoh struktury modelu i włas- 
n°śoi rozkładów prawdopodobieństwa zmiennych wejściowych oełem 
Zw ifkszenia dokładnośoi pomiarów zmiennych wyjśoiowyoh. 


Przedstawiony wyżej problem redukcji błędów znaoznie się 
komplikuje w przypadku gdy mamy do ognienia z obserwaojami 
8 korei owan y m i. Dane wyjśoiowe uzyskiwane z symulacji są na ogół 
au toskorelowane (funkoja autokorelaoji próbki Rg.^ ^0 dla 
8 ^ t). w tym wypadku nie można stosować wielu wygodnych metod 
3ta 'tyetycziych, prawdziwyoh dla niezależnyoh statystyoznie ob- 
6e rwaoji. Ignorowanie autokorelaoji jest niedopuszczalne, ponie- 
Prowadzi do błędnyoh ooen. Odohylenie standardowe wartośoi 
6l, odniQj jest teraz określone wzorem 





(1 - |s| /n) R a 


R 


e - funkcja autokorelacji 


nieznormalizowana 


Jak widać,aby uzyskać tę samą dokładność potrzebne są w tym 
^Padku znaoznie dłuższe próbki. Obliczenia związane z wyzna- 
0z9 ni Qm f Un koji autokorelaoji są dla długich próbek bardzo 
° z ^soohłonne. Aby określić minimalne n, przy którym b-< CK 
^ - zakładany poziom błędu), nie można uniknąć obliczenia 
fu ńkoji autokorelao ji. W związku z tym badania i poszukiwania 
k°hoentrują się na takioh algorytmaoh, które minimalizują kosz- 
2wią zane z tymi obliczeniami. Przykładem takiej metody może 
met-oda pośrednia określenia funkoji korelaoji, drogą znaj- 
d ° w ania modelu autoregresyjnego badanego przebiegu przypadkowe- 
(sekwenoji obserwaoji). Model taki ma postaćt 
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C b a - fi 

- sekwencja statystycznie niezależnych zmiennych przy" 
• padkowyoh o jednakowym rozkładzie 

X/| • • • X^"- sekwencja obserwaoji skorelowanych 
n 

p = — C - wartość średnia sekwencji obserwacji 
n i=1 

b 0 . - współczynniki modelu autoregresyjnego 
r - rząd modelu autoregresyjnego 1 < r < 5 

Funkcję autokorelaoji badanej sekwencji obserwacji można wy' 
razić za pomocą współczynników b g modelu autoregresyjnego. 

Powyższe zagadnienia omówione są szerzej w [2], [ 5 ], [6], 

[ 7 ], [ 8 ], [ 10 ]. 

4. PRZYKŁAD! 

Rozpatrzmy dwa przykładowe podsystemy systemu komutaoji mel" 
dunków([3] oraz [li] , [12] )• 

Przykład 1 

Rys. 1 ilustruje zasadę działania systemu dynamicznej reze?"' 
wacji buforów pamięci operacyjnej dla segmentów meldunków 
wejściowyoh i wyjściowych. Zakradamy, że system ten współpraco' 
je z M-liniami transmisji danych. Przyjmujemy ponadto, że zna* 10 
są ro zkła dy prawdopodobieństwa długości meldunków oraz odstępu 
ozasowych między kolejnymi meldunkami. Rozpatrywana tutaj te oh' 
nika segmentacji meldunków i przydziału buforów ma na oelu 
zwiększenie wykorzystania pamięoi operacyjnej. Jak wynika z 
rys. 1 należy dążyć do minimalizacji czasu blokowania 5. 
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Re **rwacja 

buforu 

r, 


.Kt 

Kt" 


Ul 




i. 


Transmisja segmentu i 


Żądanie 
buforu u 

L 


i+i 


-1 

zwolnienie 

buforu 



a 

d i+1 

r ui 


rez. 

buf. 


Transmisja seg. 1+1 


- czas zajętości buforu 




(dla segmentu i) 

- średni czas zajętości buforu 

- czas blokowania buforu (od momentu rezerwacji do chwili 
rozpoczęcia transmisji) dla segmentu i 

- średni czas blokowania buforu 

3 - czas (średni czas) oczekiwania na rezerwację buforu 

- opóźnienie żądania buforu dla segmentu (i+1) względem po¬ 
czątku transmisji segmentu (i) 

Pałanie systemu zostaje zakłócone, gdy bufor dla segmen- 


Ti 

? 

d,. 


i+1 




nie zostanie zarezerwowany do ohwili zakończenia trans¬ 
zą ” 8 egmentu i (strata informaoji w przypadku meldunków od- 
) s ^oh lub przerwa w transmisji w przypadku meldunków wysy- 
tor. 6 a y 


d i > 




6^ Wz elędów ekonomioznyoh rzadko dąży się do oałkowitego wy- 
D^^wania wspo mn ianych zakłóceń, a raczej do utrzymania 
ją ^Podobieństwa ioh występowania na zadanym, odpowiednio 
■irą 1 poziomie. Zatem problem można sformułować jako poszuki- 
* Minimalnej liozby buforów, przy ^pełnieniu warunku 


< oe 


2 ie rt 

.Kr oznaoza maksymalną wartość d, która nie powoduje za- 




» a a - zadany poziom prawdopodobieństwa. 
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Rozwiązanie tego zagadnienia jest trudne ze względu na to f 
że średni ozas obsługi z jest zależny od d, które z kolei 
jest funkcją z i P. Oozywiście, w omawianym systemie, można 
sformułować kilka innych problemów projektowych jak np. poszu¬ 
kiwanie maksymalnej liczby, lii. linii transmisji, z którymi 
może współpracować dany system, biorąc pod uwagę ograniczenia 
pamięoi operacyjnej (P buforów) lub też zagadnienie współpra¬ 
cy z liniami transmisji danych o różnych przepustowościach i 
natężeniach napływu meldunków* Rozwiązanie postawionych probl 0 " 
mów metodami analitycznymi jest praktycznie bardzo trudne l u ^ 
wręcz nieosiągalne. Technika symulacyjna pozwala znacznie przy" 
śpieszyć i uprościć proces projektowania. 

Na marginesie rozważań dotyczących omawianego wyżej przykł&" 
du warto wspomnieć o pewnym problemie praktycznym związanym 
z techniką symulacji: modelowaniu rzadkich zjawisk. 

Aby móc poprawnie rozwiązać przedstawiony wyżej problem na - " 
leży dokonywać pomiaru prawdopodobieństw występowania bardzo 
rzadkich zakłóceń w odbiorze lub nadawaniu informacji, wynika¬ 
jących z braku pamięci. Przyjmujemy, że wspomniane prawdopodo¬ 
bieństwo 

l e l > d m) 4 10 ' 3 

Zatem rozpatrywane zakłócenie występuje średnio rzadziej ' 
raz na tysiąc segmentów. Aby uzyskać wystarczająco wiarygoan3 
estymatę rozważanego prawdopodobieństwa należałoby kontynuować 
eksperyment symulacyjny tak długo, aż rozpatrywane zdarzenie 
wystąpi wystarozającą ilość razy np. sto razy, co odpowiada 
symulacji obsługi 100 000 segmentów meldunków. 

Jeżeli weźmiemy pod uwagę fakt, że do uzyskania zadowalają" 
cych estymat pozostałyoh wielkości stochastyoznyoh występują" 
oych w modelu, np. ozasów d, ź, wystaroza na ogół obserwacja 
obsługi ~5000 segmentów, to widzimy, że należy poszukiwać 
przybliżonych pośrednich sposobów obliczenia szukanej wielkoś" 
ci prawdopodobieństwa. Wyznaozanie bezpośrednie jest niemożli" 
we ze względów ekonomiczno—czasowych. 
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traktyozne rozwiązanie omówionego zagadnienia opiera się na 
P°dęoiu tzw* statystyk wartości ekstremalnych (tzn. własności 
8 taty stycznych wartości ekstremalnych - minimalnych i maksy mai- 
tych - próhek losowych pochodzących z rozpatrywanego procesu)* 
korzystamy przy tym z faktu, że większość spotykanych w prakty- 
° e rozkładów prawdopodobieństwa można aproksymować funkcją wy¬ 
kładniczą w części odpowiadającej małym, marginalnym prawdopo¬ 
dobieństwom* Aby skonstruować wspomnianą aproksymację wystarcza 
° z ęsto stosunkowo niewielkie wydłużenie próbki (np. z 5000 do 
10 000 w omawianym przykładzie)* Posługując się następnie funk- 
aproksymującą można uzyskać poprawne oceny statystyozne 
rz adkich zjawisk* 

Wyk ład 2 * Wybór algorytmu obsługi odwołań do pamięci dyskowej 

Złe wykorzystanie pamięci zewnętrznych (bębny, dyski) może 
w 2 naoznym stopniu pogarszać efektywność systemów cyfrowych. 
P° 2 Patrzny zatem zagadnienie wyboru optymalnego algorytmu obsłu- 
81 odwołań do pamięci dyskowej (przedmiotem naszego zainteresowa¬ 
na S ą wyłącznie dyski z ruchomymi głowicami) * Wybór dokonywany 
b ^2ie spośród znanych algorytmów obsługi. Każdy z nich posiada 
8w °iste, korzystne cechy w wąskim przedziale natężenia zgłoszeń. 
^ r °ble m polegać więc może na dokonaniu kombinacji dwóch, lub 
n^kszej liczby algorytmów podstawowych tak, aby zapewnić żą- 
ceohy w szerokim zakresie zmienności natężeń odwołań* 

Przyjmijmy przykładowo następującą funkcję - kryterium: 

= T S i ^ bW i + 0 6 

* 

S U) - średni ozas obsługi odwołania do dysku (dla i-tego 
algorytmu) • 

V*) - średni ozaB oczekiwania odwołania do dysku od momen¬ 

tu przybycia do kolejki do chwili zakońozenia obsłu¬ 
gi (dla i-tego algorytmu) 

W- _ wariancja ozasu oczekiwania (dla i-tego algorytmu; 

- średnia częstotliwość napływu odwołań do dysku w 
ciągu 1 s. 

’ k* o - współczynniki wagi 
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Mająo kryterium przystępujemy do eksperymentu symulacyjnego 
z poszczególnymi algorytmami. Z każdego przebiegu symulaoyjneg 0 
otrzymujemy wartośoi Q^. Następnie szukamy ekstremum (minimum) 
Q lf Indeks i, przy którym funkoja-kryterium osiąga ekstremum, 
określa algorytm optymalny ze względu na to kryterium. 


5. PEWNE ASPEKT! OPTYMALIZACJI PROJEKTOWANYCH SYSTEMÓW 

Problemy przedstawione w powyższyoh przykładach można próbo' 
waó rozwiązywać metodami tradyoyjnymi w sposób iteraoyjnyj wy' 
konuje się eksperyment symulaoyjny, analizuje uzyskane wyni' 
ki, na podstawie któryoh można określić nowe wartośoi parame¬ 
trów modelu, dla kolejnego eksperymentu. Metoda ta stosunkowo 
dobrze zdaje egzamin w przypadkaoh strukturalnie prostyoh mo¬ 
deli o niezbyt dużej liczbie zmiennych. Gdy mamy do ozynienia 
z problemem zbiorosym wielowymiarowym trudno jest, nie znajdo 
wyraźnie zależności wiążącyoh rozpatrywane zmienne z kryteria 11 
ooeny, określać w sposób świadomy, efektywny kierunki poszuki" 
wań lepszyoh rozwiązań. Tak więc procedurę poszukiwania dopust 
o żalnego lub najlepszego rozwiązania należy wzbogacić o możll' 
wośoi i środki identyfikacji, na bieżąoo, na podstawie zgroma¬ 
dzonych informacji, podstawowyoh związków i zależnośoi między 
zmiennymi modelu. W tej sytuaoji problem może się okazać obli' 
ozeniowo bardzo ozasoohłonny, komplikując i ograniozająo tym 
samym praoe projektowe. 

Spróbujmy zatem sformułować podstawowe wymagania dla syste' 
mu programowego, który w sposób automatyozny lub być może pół' 
automatyozny przy współpraoy analityka umożliwiłby uzyskani® 
rozwiązania zbliżonego do optymalnego. Pormułująo model sym^' 
laoyjny, który będzie wykorzystany do oelów predykoji charak¬ 
terystyk użytkowyoh, zwłaszoza w przypadku gdy nie dysponuje®? 
odpowiednim doświadczeniem w projektowaniu rozpatrywanej kia®? 
systemów, łatwo popada się w nadmierną drobiazgowość opisu 
wierząo, że w ten sposób łatwiej uzyskuje się zadowalające *v 
niki eksperymentu. Być może postępowanie to jest wynikiem na¬ 
wyków charakterystycznyoh dla programistówi aby dobrze zapro' 
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Bramować problem obliozeniowy należy wnikliwie rozpatrzyć 
Ws ^stkie szozegóły, możliwośoi, kombinaoje itp. Postępowanie 
przeniesione na grunt modelowania, daje na ogół wyniki ne- 
Batywne, powoduje trudnośoi obliozeniowe. Model powinien zawsze 
możliwie syntetyoznie uwzględniać aspekty badanego obiektu (nie 
W 0 zystkie), interesująoe jedynie z punktu widzenia rozwiązywane¬ 
go Problemu. Należy tutaj raz jeszoze przypomnieć, że model jest 
z awsze narzędziem podporządkowanym oelom eksperymentalnym. 

Mająo na uwadze automatyzaoję eksperymentalnej fazy projek¬ 
towania należy nadmierną drobiazgowośó modelu (duża liczba 
Plennych nie wpływająoyoh na kryterium ooery) uznać za szkodli— 
Wl U' Z drugiej strony trzeba pamiętać, że analityk konstruujący 
^odel systemu może nie wiedzieć lub nie spodziewać się istnie¬ 
ją pewnyoh oddziaływań i związków wewnętrzny oh (oddziaływania 
&ogą mieć oharakter zanikająoy, przejśoiowy, wystąpienie 
ef ®któw może być znaoznie opóźnione w stosunku do przyozyn) . 

więo w eksperymenoie symulaoyjnym uwzględnić należy etap 
^jygotowawozy, mający na oelu testowanie i minimalizaoję mo- 
'Mu. Omówione wyżej badania dokonywane są za pomocą metod ana- 
l *zy statystyoznej: analizy ozynnikowej oraz analizy wariancji. 

Dysponująo odpowiednio przygotowanymi modelami można przy- 
Q tąpić do następnej fazy eksperymentuj wyboru odpowiednioh me- 
to d poszukiwania rozwiązania optymalnego. Podstawowym czynni¬ 
kom rzutująoym na tok dalszego postępowania jest oharakter 
Plennyoh występująoyoh w modelu. 

Ahalizująo przykład 1 stwierdzamy, że występują w nim wy¬ 
rżnie zmienne o oharakterze oiągłym. W tej sytuaoji można 
Panować wykorzystanie metod programowania matematycznego (np. 
5t0 Sramowania liniowego lub metod najszybszego spadku) do wy- 
8ft aozania poszukiwanego rozwiązania optymalnego. Nasuwa się 
n ło następny problem raojonalnego wyboru odpowiedniej metody 
klasy metod najbardziej przydatnyoh i odpowiednioh do roz- 
^^Zania naszego zagadnienia. 

Zrozumiałe jest, że ze względów ozasowo-ekonomloznyoh wybie- 
będziemy metody szybko zbieżne, tzn. gradientowe [ 5 ]• Za8a “ 
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dę postępowania w przypadku stosowania wspomnianych metod gra¬ 
dientowych streścić można w następujących punktach: 

1. wybieramy punkt startowy (projekt początkowy) dla procedury 

2. .dokonujemy liniowej aproksymacji (hiperpłaszczyzna aproksy- 
mująca) funkcji celu (odpowiedź systemu) w otoczeniu punktu 
startowego. Wykorzystuje się w tym celu standardowe techni¬ 
ki statystyczne (metoda aproksymacji średniokwadratowej). 

W wyniku takiego postępowania wyznaczamy kierunek poszukiwać 
rozwiązania optymalnego. 

3. wzdłuż wyznaczonego uprzednio kierunku dokonujemy poszukiwać 
dążąc do ustalenia punktu ekstremalnego (minimum lub maksi¬ 
mum) , tzn. takiego rozwiązania, że istnieje małe prawdopodo¬ 
bieństwo polepszenia uzyskanych rezultatów. Należy w tym 
miejscu zwróoić uwagę na poważny problem praktyczny doboru 
długości kroku dla poszukiwań kierunkowych. Zbyt mały krok 
powoduje znaczny wzrost obliczeń, wolniejsze posuwanie się 

w kierunku optimum; zbyt duży krok może doprowadzić do omi- 
nięoia lub trudności w zlokalizowaniu ekstremum. Nie istnie' 
ją ogólne reguły doboru długości kroku, które można by za¬ 
akceptować do szerokiej klasy problemów. Praktyczny dobór 
odbywa się zwykle w sposób doświadczalny. 

4. otrzymane w p. 3 ekstremum kierunkowe staje się punktem 
startowym do nowego cyklu iteraoyjnego. Proces poszukiwanie 
rozwiązania optymalnego przerywa się, gdy zostaną spełnion 0 
warunki wskazujące, że prawdopodobieństwo otrzymania leps z ' J- ' 
go rozwiązania jest odpowiednio małe. W przypadku gdy apro¬ 
ksymacja liniowa nie wystarcza do prawidłowego wyznaczenia 
dalszy oh kierunków poszukiwań ekstremum, np. w przypadkach 
punktu siodłowego lub w pobliżu punktu ekstremalnego, wyko¬ 
rzystuje się aproksymację kwadratową. 
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Wspomniano metody gradientowe wymagają różniczkowalności 
Aukcji celu (kryterium). Może się więc zdarzyć (choć wydaje 
S ^> że niezbyt często) , że będziemy zmuszeni korzystać z me- 
^ bezgradientowych. Jedną z nich najbardziej naturalną, którą 
02 y wspomnieć w tym miejscu jest metoda uzmiennienia poje- 


hej 


Qz yoh ozynników. Dokonując zmian wartości pojedynczej zmien- 
Przy pozostałych ustalonych dąży się, oczywiście, do osiąg¬ 
ała 
ty® 


ekstremum (kierunek poszukiwania ekstremum jest więc w 


Si 


Przypadku zgodny z kierunkiem wybranej osi współrzędnych) . 
\ 8 t tępnie ustalając poprzednią zmiennej na poziomie osiągniętej 
ychozas wartości eksbremalnej (największej lub nujmniej- 
*" i uzmiennia się inny czynnik. Po wykonaniu opisanych prób 
. a Wa zystkich n-czynnikóv/ powraca się do czynnika pierwszego 
P°hawia się cykl poszukiwań. Proces optymalizacji zostaje 
dymany, gdy zmiany żadnego czynnika nie powodują polepsze- 
w ^rtości funkcji celu. Jak widać jest to metoda bardzo pros- 


’ ^Sodna do stosowania. Jej podstawową wadą jest ogranicze- 
f 0 kierunków poszukiwań (kierunki osi głównych układu współ- 
ę<3 Pych). Może to prowadzić do błędnycn wyniKów, tzn. zatrzy- 
się procedury daleko od punktu ekstremalnego, np. w przy- 
‘ u "ostrego grzbietu" funkcji celu, nie równoległego do żad- 
: ° s i współrzędnych. Omówiona metoda, jak łatwo zauważyć, 
°dznacza się szybką zbieżnością. Liczba eksperymentów jaką 
p wykonać, aby zbliżyć się do optimum jest bardzo duża. 

tematyka wykorzystania programowania matematycznego do opty- 
iza -cji w dziedzinie procesów dyskretnych, z wykorzystaniem 
^ 3 ^ e tymentów symulacyjnych, jest aktualnie w skali światowej 
y,^ 20 ®ało rozpoznana. Nieliczne ośrodki amerykańskie przepro- 
prace badawcze w tej dziedzinie i na podstawie fragmen- 
? doniesień można wnioskować t że wyniki są pozytywne. 


^ 0 : 


QlQ » trudno obecnie ooeniać przydatność poszczególnych klas 


^ -rytmów. Wydaje się, że podstawowym problemom limitującym 
6l?S:Sf ł możliwość zastosowań omawianych metod są koszty. Prowa- 
, , ' J,J eksperymentów optymalizacyjnych dla złożonych systemów 
^' bardzo czasochłonne, przy czym czas ten zużywany jest 

na przebiegi symulacyjne. Dotychczasowe doświadczenia 
Dj. że traktując indywidualnie każdy z rozwiązywalnych 

0bl emów (mowa o problemach średniej wielkości), można dla 
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wielu z nich, na ogół drogą odpowiednich dekompozycji, aproksy' 
macji, przekształceń uzyskać zadowalające rezultaty. 

Pozostał jeszcze problem optymalizacji z ograniczeniami. 
Wszystkie powyższe uwagi zaohowują swą słuszność. W przedsta¬ 
wionym ujęciu problemu wykorzystanie metod optymalizacji z ogr 9 '’ 
niczeniami (np. metody wykorzystujące funkcję kary) prowadzi 
jedynie do dalszego zwiększenia liczby wymaganych obliczeń 
(przebiegów symulacyjnych). 

Jeżeli w rozpatrywanym problemie występują zmienne typu dyS' 
kretnego (decyzyjne), jak np. w przykładzie 2, nie można plah°' 
wać wykorzystania metod opisanych wyżej. Wartości liczbowe ta¬ 
kich zmiennych nie mają żadnego związku z wartośoią przyjęteg 0 
kryterium oceny (np. indeksy algorytmów, które są reprezento^ 8 ' 
ne w modelu przez pewną zmienną). W tej sytuacji, aby dokonać 
wyboru najlepszego rozwiązania należy korzystać z metod anal*^ 
czynnikowej [5]• 

6. ZAKOŃCZENIE 

/ 

Artykuł porusza niektóre istotne problemy, które wyłaniaj 3 
się w ozasie projektowania złożonych systemów za pomocą model 0 
wania symulacyjnego. 

Oczywiście jest to tylko część problemów. Nie omówiono tu 
takich istotnych spraw jak dobór języka symulaoyjnego do mode¬ 
lowania wybranego obiektu, modelowanie środowiska, w który® 
symulowany system jest "zanurzony". 

Artykuł koncentruje się głównie na etapie eksperymentu z S° 
towym modelem. Autorzy zwraoają uwagę na możliwość zautomatyZ 0 
wania eksperymentu, tzn. powiązania przebiegów symulacyjnych 
z analizą wyników i optymalizacją parametrów systemu. 
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MOflEJMPOBAHHE H CHMyjMIHOHHHtl 3KCHEPMMEHT B IIPOEKTMPOBAHHH 

BbrmcMTEHBmjx chctem 


Pe'3KMe 


CjIOJŁHOCTB 00BpeM6HHUX BŁWHCJIHTeJIŁHŁDC CH0T8M, OÓyOJIOBJieH- 
Haa P&3BKTH8M $yHKHEOHaJIBHHX B03M0KH0CTeft BH*IMCJIHTeJIBHHX 
CpeUCTB, BHCOKHO TpeóOBOHHH 0TH0CHT6JIBH0 H&A6SH0CTH MaTOtf*©" 
ne^emw sacTBBJUDOT npooKTupoBuoiKOB nmpoKO ncnojiB30BaTB u 
pa3BHBaTB HHCTpyMeHTH npOrpaMMHpOBaHHH, nO3BOJUH0mne ÓHCTpO 
npOBepHTB 2 OIieHHBaTB B K0JUIH6CTB6HH0M OTHOffl0HHH npOCKTHH© 
KOHuenmm. 

B HaoToameft pa3paÓ0TKe 3aTparaBaiDTca cymecTBeHHHe npo- 
dJieMU, noEBJumwecsi b npouecce npoeKTHpoBaHHH ojio;khhx ohc- 
T6m nyreM CHMyjumHOHHOro MOflejmpoBaHHH. 3 th npoÓJieMH npo- 

HJUDOCTpupOBaHH npaKTHHeCKHMH npHMepaMH. 

I 

MODELLING AND SIMULATION EXPERIMENT IN COMPUTER SYSTEMS DESIGN 
Summary 

The increase of current digital systems complexity resulted froffl & 
development of functional possibllitles of hardware and user*s requi r ^ 
ments concerning software effectiveness enaourage software designer 0 
use and deyelop programming tools for fast yerification and evalua*i oJJ 
of design concepts. 

d*' 

This paper presents basie problems arising during complex system* ^ 
signing which employes simulation modelling. Problems are discussed 
the base of some experiments. 


(c) Instytut Maszyn Matematycznych 
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ANALIZA SYSTEMÓW LICZĄCYCH 
METOD* SYMULACJI 

Józef MAROjłSKI 
Centrum Obliczeniowe PAN 
Pracę złożono 10.1 .1974 


*aa^ 0 8ra °iG zostaną przedstawione pewne problemy 
*6* ^* 0wa nia metody symulacji do badania syste- 
innymi będą omówione takie 
tych ? nŁa Jaki weryfikacja modeli symulacyj- 
v,iar yg°d n °ść wyników symulacji, adaptacja 
w «g 0 Uczącego do potrzeb ośrodka obliczenio- 
W skrócie omówione zostaną również 
C *^°ych**^ 8Ie P race dotyczące badań systemów li- 
1 * wykorzystaniem metody symulacji. 


Spis treści 

Vs T«P 

\ *° 2Wl 4ZYVANIE PROBLEMÓW OPROGRAMOWANIA METODA symulacji 
^ Ry *lKACJA MODELI SYMULACYJNYCH 
S. URYgo DNOSÓ WYNIKÓW SYMULACJI 

2fi OLAD SYSTEMÓW ANALIZY I SZACOWANIA SYSTEMÓW LICZĄCYCH 


1. 


*STSp 


M 

t m °inQnci e kiedy maszyny cyfrowe stały się powszechnym na- 


h Wil 
^oh 

0^4 1 °6romnego znaozenia nabrał problem szaoowania i wyboru 


w badaniach naukowyoh oraz zastosowaniach komerojal- 


dla dany oh zastosowań systemów licząoych. Problem 
^ szczególnie ważny podozas instalowania systemów do 

nw *rzania danych. Systemy te z reguły wieloprogramowe, 
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często wieloprocesorowe stają się tak złożone, że nawet naj— 
bardziej doświadczony projektant nie jest w stanie dokonać icb 
oszaoowania w sposób intuicyjny • Użytkownicy coraz częściej V°~ 
szukują narzędzi do porównywania konkurencyjnych propozycji 
różny oh firm komputerowych. 

Referat stanowi pewnego rodzaju przegląd zagadnień, w rozwa* 
żaniu których wykorzystuje się lub można wykorzystać jedną z 
najodpowiedniejszych dla maszyn cyfrowych metod, metodę symula' 
cji* 


Poza tym omówione będą krótko dwa z podstawowych zagadnień 
związanych z metodą symulacji: zagadnienie weryfikacji modeli 
symulacyjnych oraz zagadnienie wiarygodności wyników symulacji* 

Na zakończenie omówione zostaną różne rozwiązania zarówno 
sprzętowe jak i programowe opracowane przez różne firmy cele 111 
przeprowadzania analiz działania różnych systemów. 


2. ROZWIĄZYWANIE PROBLEMÓW OPROGRAMOTANIA METODĄ SYMULACJI 

Z zagadnieniem analizy i oceny systemów cyfrowych w bardz° 
ścisły sposób związane jest ustalenie odpowiednich kryteriów 
tej oceny. Od dawna kryteria stosowane do tych celów ulegają 
ciągłym zmianom, a najczęściej spotykana jest tzw. moc syste¬ 
mu oraz koszt jego instalacji* Ponieważ istnieje ścisła za¬ 
leżność pomiędzy mocą systemu a wspomnianymi kosztami instal^ 
cji i eksploatacji nasuwa się całkiem naturalne dążenie do 
pewnego rodzaju optymalizacji tych wielkości* Oczywiście opty" 
malizacja taka jest możliwa wówczas, kiedy jesteśmy w stanie 
określić odpowiednie miary analizowanych wielkości. 

Optymalizaoja systemu jest możliwa tylko wtedy, kiedy ietu^ 0 
je możliwość zmiany wewnętrznej struktury danego systemu; ki*^ 
pp. można rezygnować z pewnych funkcji systemu kosztem zwięk¬ 
szenia mocy tego systemu itp. 

Metoda symulacji ma szczególne znaczenie podczas instalo**^ 
nia systemów przetwarzania danych, czy systemów służących 
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ferowania obiektami przemysłowymi. W systemaob przetwarzania 
^anyoh, szozególnie tyoh złożonych z programów parametryzowa- 
symulacja służy do ustalania najbardziej odpowiednich 
^rametrów dla danego środowiska. Dobierane są parametry okreś- 
* a dąoe zbiory danych oraz rodzaje operaoji wykonywanych na tyoh 
z Horaoh w tym środowisku. Podobnie przedstawia się problem 
82 &oowania systemów do sterowania prooesami, w których można 
^ ol£ Ohywać zmian harmonogramów działania programów obsługi itp. 


* ostatnim czasie pojawiło się wiele problemów natury znacz¬ 
ki 10 ogólniejszej niż wspomniano wyżej. Jednym z nioh jest tzw. 
^zys softwarogowy", na który składają się dwa zasadnicze 
^bierny nierozwiązane dotyohozas w sposób definitywny. Pro- 
eai Pierwszy to niezadowolenie użytkowników, którzy uważają, 
obeonie dostępne systemy lioząoe nie zaspokajają ioh potrzeb. 
Pensje te, występująoe niezależnie od etapu rozwoju systemów 
°ząoyoh, można dość łatwo wytłumaozyć. Nawet częste kontakty 
1)10 taktantów systemów z użytkownikami, które niektórzy postulu- 
w sposób generalny nie poprawiają sytuaoji pod tym wzglę- 
Bowiem potrzeby różnyoh użytkowników, chociaż dotyczą te- 
8 amego profilu obliozeń, mogą być zasadniczo różne. Poza 
system liczący zadowalająoy jednego użytkownika, z którym 
^jekt konsultowano może byó nieodpowiedni dla wszystkich po- 
2 ° a tały 0 j 1 użytkowników. Jednym z odpowiednioh rozwiązań tego 
Obłemu wydaje się budowa systemów otwartyoh, w skład których 
takie elementy oprogramowania i sprzętu, które zas- 
^hjają bieżące potrzeby danego użytkownika. Dobór tyoh elemen- 
szczególnie przy bardziej złożonych systemach, nie jest 
^liwy b ez zastosowania odpowiednich metod. Jedną z takich me- 
^ Jest metoda symulaoji. Nie należy z tego wnioskować, że me- 
’ 0<ia ta zlikwiduje wspomniany problem "kryzysu software'owego", 

/Cl Ciemniej może ona pomóo w jego złagodzeniu. Oozywiście w 
^ * °elu należy przyjąć odpowiednie metody projektowania sys- 
lioząoyoh i operacyjnych. Szozególnie niezbędna okazuje 
^ bu struktura modularna, pozwala ona bowiem na dołąozanie, 
i ^Bhtu e j. 11; j. e wymianę odpowiednioh dla danego użytkownika modu- 
Programowyoh. 
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Wydaje się, że metoda symulacji może również dopomóc w zła¬ 
godzeniu drugiego problemu "kryzysu software'owego". Mianowi¬ 
cie może przyczynić się do obniżenia kosztów wytwarzania opro¬ 
gramowania, jeśli będzie ono mogło się zmieniać w zależności 
od potrzeb użytkowników, natomiast jego elementy składowe będ4 
pobierane ze stałego zbioru programów, a nie projektowane dla 
każdego typu użytkowników niezależnie. Szczególnie jest to waż" 
ne podczas oprogramowywania serii maszyn powiązanych wspólnym 
oprogramowaniem. Symulacja pozwala na dobór odpowiednich zbio¬ 
rów programów stanowiących np. systemy operacyjne. 

Jeszcze innym problemem, może mniej związanym z "kryzysem 
software'owym" lecz równie ważnym, jest problem samodzielnego 
wprowadzania zmian do systemu przez różnych użytkowników. Pró¬ 
by takie w ostatnim czasie notujemy coraz częściej. Aby ułatwi^ 
dokonywanie takich zmian konieczne są pewne środki pozwalające 
na obserwaoję współdziałania poszczególnych elementów oprogra¬ 
mowania. I tak można wbudować do systemów odpowiednie programy 
"podglądające" oraz pozwalające na odpowiednie zmiany w opro¬ 
gramowaniu. Wydaje się, że dopiero połączenie tych ułatwień z 
metodą symulacji może dać odpowiednie efekty. Można bowiem dzi^ 
ki temu obserwować różne aspekty współdziałania systemu przed 
i po ewentualnych zmianach dokonywanych przez użytkownika w 
ternie i jego modelu symulacyjnym. W przypadku kiedy producent 
dostarcza razem z systemem jego model symulacyjny, koszty zwiS' 
zane ze zmianą takiego systemu znacznie się obniża. 

Z tym samym zagadnieniem wiąże się sprawa testowania we¬ 
wnętrznego systemów. Jeśli wspomniany model systemu jest do¬ 
statecznie szczegółowy, wówczas testowanie można znacznie prz?" 
spieszyć przez testowanie modelu, traktując testowane elementy 
bardziej szozegółowo, a elementy już przetestowane lub w dany* 0 
momencie nieistotne bardziej ogólnie. Taki model symulacyjny 
może stanowić równooześnie pewnego rodzaju opis dokumentacyj*tf 
danego systemu. 
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3 * *BRrpfkACJA MODELI SYMULACYJNYCH 

^stosowanie metody symulacji jak i innych metod nastręoza 
trudnośoi, inaczej mówiąc, stwarza pewne problemy. Jed- 

Y]ri 

z nich jest weryfikaoja modeli, czyli stwierdzenie zgodnoś- 
tt °deli z systemami rzeózywistymi. 


4*e 


zastosowaniach tej metody można zauważyć dwa zasadnicze 
weryfikacji modeli. Pierwszy z nich polega na stwier- 


a iu zgodności modelu systemu z samym systemem. Z reguły od- 
^ a się p rzez porównanie pewnyoh wyników otrzymanyoh w oza- 
^ziałania systemu rzeozywistego z wynikami otrzymanymi w 
działania modelu tego systemu. Jeśli wyniki będą zgodne 
°^Powied n ią toleranoją, wówozas możemy stwierdzić, że model 
. J io iwle odzwierciedla system. Oozywiście taka weryfikaoja 
^ * a °żliwa tylko wówozas, kiedy istnieje system rzeczywisty 

^żemy uzyskać pewne obserwacje podozas jego działania. 

ltla ozej przedstawia się sytuaoja w przypadku, kiedy system 
zy wiaty nie i 8 tnieje, jest w stadium projektu. Jak również 
Wypadku kiedy musimy, np. ze względu na wielkość symulowa* 
80 systemu, ograniozyć się do uwzględnienia w modelu tylko 
elct óiyoh elementów systemu w sposób szozegółowy a wyelimino- 
^ A s ozęśoiowo lub całkowioie innych. W tyoh przypadkach model 
^^Ikowany jest najczęściej tzw. metodą prób i błędów. Wyko- 




tuj 

"lod 


h si § działania symulacyjne z uwzględnieniem danego elementu 
z Jego szczegółowym modelem i bez tego elementu lub z jego 


bardziej ogólnym. Porównanie uzyskanych wyników pozwala 
^ e °ydować ozy d any element ma istotne znaozenie i Jak należy 

i taktować w dalszy oh badaniaoh. Powtarzająo ten proces wie- 

°kr> ( - - 

n* 


° tn ie dla ooraz to innyoh elementów modelu możemy w efek- 


% Uz y8kać model całego systemu, który będzie najodpowiedniej- 
dalszyoh badań. 


^ARYGODNOŚC wyników symulacji 

1 ltl hym, niemniej ważnym, problemem występującym w symulaoji 


Wiarygodność uzyskanyoh wyników. 
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Podczas każdego działania symulacyjnego generowane są pew¬ 
ne wielkości zwane wartościami oeoh modelu danego systemu*^ • 
Ponieważ z reguły symulacja opiera się na pojawieniu się zda¬ 
rzeń w sposób losowy, w celu oszaoowania jakiejś wielkośoi do¬ 
konuje się odpowiedniej liczby działań symulaoyjnych. Wobeo 
tego dla jednej cechy otrzymujemy wiele wartości z poszczegól¬ 
nych działań* W takim przypadku posługujemy się oszacowaniami 
wartości średnich poszczególnych oeoh. Ponieważ wartośoi śred¬ 
nie tyoh oeoh są również wielkościami losowymi, stosujemy tzw* 
szaoowanie przedziałem. 


Opierająo się na centralnym twierdzeniu granicznym, które 
mówi, że dla dostateoznie dużej liczby prób n, teoretyczny 
rozkład z próby można z dużą dokładnośoią aproksymować za poff 0 ' 
cą rozkładu normalnego, możemy twierdzić z prawdopodobieństwo® 
1-a , że wielkość błędu x-p, który popełniamy przyjmując 
jako oszacowanie wartości średniej p , będzie mniejsza niż 
, gdzie Z a oznacza współczynnik ufności, a <5 
oznacza odohylenie standardowe populacji, które zastępujemy 
odchyleniem standardowym z próby 


8 


■ViE 


|x i - 




W większości przypadków z zastosowania metody symulacji '•'O'" 
ciągamy wnioski na podstawie wartości średnich odpowiednich 
cech. W takiej sytuacji jednym z ważniejszych elementów proce" 
su symulacji jest przeprowadzenie testu istotności różnic po" 
między wartościami średnimi odpowiednich cech dla różnych pr^ e 
biegów symulacyjnych. Chodzi w tym przypadku o stwierdzenie f 
czy różnica między średnią wartością cechy dla jednego dział*" 
nia symulacyjnego i taką samą średnią dla innego działania 
przy zmienionyoh warunkach jest wielkością przypadkową, czy 
rzeczywiście zależy od zmiany warunków. Stosuje się w takich 
przypadkach zwykle test t-Studenta oparty na wzorze 



V 


s i + 


n-T 


«) 


Terminu tego używamy w tym samym sensie co przy badaniach statystyk 
nych systemów rzeczywistych. 
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^ zle i Eg oznaozają odpowiednio testowane średnie, a 
1 * 8 2 odpowiednie warianoje, 

obliczoną wartość testową porównuje się z wartośoią gra- 
tt *°*ną rozkładu t dla 2n-2 stopni swobody przy założonym po- 
z ^°kle ufnośoi. Jeśli moduł obiłozonęj wartośoi testowej jest 
**9kszy 0( j wartośoi granioznej, wówozas z zadanym prawdopodo- 
®fcwem możemy twierdzić, że poszozególne średnie różnią się 

a *Wty sobą w sposób Istotny a różni o a nie jest dziełem przy- 

Padku. 


Mówiona metoda testowania istotnośoi różnio pomiędzy odpo- 
^ la ónimi średnimi może służyć również podozas podejmowania de- 
^ 2 3i, w trakoie budowy modelu, ozy dany element ma istotne 
łożenie, ozy też można go odrzuoić. 


t 

’ P RZEGL4D SYSTEMÓW ANALIZY I SZACOWANIA SYSTEMÓW LICZĄCYCH 

^ zakońozenie dokonamy pewnego przeglądu istniejąoyoh sys- 
^ badania oprogramowania i sprzętu. Systeny te opierają się 
1,1 ^óżnyoh zasadaoh. Istnieją systemy sprzętowe działająoe na 
Zfle adzi e urządzeń elektronioznyoh podłąozanyoh bezpośrednio do 
^ 8 tam6w lioząoyob, speojalne programy włączane do systemu 
l ®raj ąoe i analizujące dane uzyskiwane w ozasie praoy anali- 
*° w aneg 0 systemu, jak również symulatory imitujące praoę bada- 
^ Qli systemów. 


^daje się, że najodpowiedniejsze w takioh szaoowaniaoh są 
^ a toay pi erwsze g 0 i ostatniego typu. Urządzenia sprzętowe bo- 
t 6ta z reguły nie oboiążają jednostki oentralnej w badanym sys- 
nie ma dodatkowyoh narzutów na zarządzanie takim anali- 
x Symulatory z kolei działają w sposób niezależny od 

jadanego systemu. Wykorzystuje się w nioh tylko informaoje uzys- 
z tyoh systemów w trybie "off—linę". 


N stomiast analizatory systemów zbudowane na zasadzie progra- 
* dają obraz nieoo sfałszowany wskutek tego, że zwiększają 
** Narzuty praoy jednostki oentralnej na zarządzanie i wyko- 
^®hio byoh programów, jak również zmniejsza się obszar wol 
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nej pamięoi operacyjnej. Z reguły takie analizatory zbudowane 
są w sposób dwuozęściony. Pierwsza z nioh praouje w ozasie 
działania analizowanego systemu i rejestruje różnego rodzaju 
dane, które następnie w sposób niezależny przetwarza druga 
ozęść analizatora, sporządzająo odpowiednie raporty. 

Przedstawiony niżej przegląd nie obejmuje na pewno wszyst¬ 
kich zbudowanyoh systemów analizy i szaoowania systemów liozą' 
oyoh. Jednak daje pewien obraz tendencji jakie panują w tej 
dziedzinie. 

Systemy oparte na urządzeniaoh sprzętowyoh oferują następu 
jące firmy: 

• Applied Computer Technology, Ino., system CPM II, 

• Applied Systems Div., system X-RAY, 

• Computer Programming a. Analysis Ino., system CPA 7700, 

• Computer Progr amm ing and Consultation, system COPAC, 

• COMRESS, system Dynaprobe/Dynapar, 

• IBM, system IS/PAR, 

• University of Califomia at Los Angeles, system SNUPER. 

Systenjy oparte na monitoraoh programowych oferują: 

• Boole a. Babbage, system CUE, 

• Computer Management Soienoes, system M—Test, 

• Computer Syneotics, Ino., system SUM, 

• IBM, system SIPE, 

• Lambda Corporation, system LEAP, 

• Standard Linear Aocelerator Center, system PROGLOOK. 

Trzeci rodzaj analizatorów tzn. symulatory oferują nastęP u 
jąoe firmy: 

• Applied Data Researoh, Ino., system SAM, 

• Applied System Division, system CASE, 

• COMRESS, system SCERT, 

• IBM, system AMAP, 

• Nippon Eleotrio Company, system PACSS 
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0r&z wiele innyoh symulatorów podawany oh w literaturze bez 
naa *y. Do najbardziej znanyoh można zaliczyć symulatory Soher- 
Goldsteina, Fine # a i Uolsaaoa oraz Katza, 

Należy sądzić, że w najbliższym ozasie nastąpi pewnego ro- 
a «Jo intensyfikaoja prao.badawozyoh dotyoząoyoh wypraoowywa- 
kryteriów oraz metod badawozyoh zarówno systemów liozącyoh 
°Peraoyjnyoh, jak również niezależnyoh programów. 


130 


Józef MAROŃSKI 


AHAJM3 BłJHMCMTEJJŁHLtK CHCTEM HFTEM CM^JIHIJJIOHHOrO METOM 
P esme 


PasBHTHe BbiMiicjmTejii)HHx chctcm Bce eme OTCTaeT OT pa3BM- 
™ npiIMeHeHHH 3THX CHCTeM B pa3HHX OÓJiaCTJDC. ^TOÓH yCKOpHTt 
paSBMTH© BHHHCJIHTejIBHHX CHCTeM, npHMeHHIOTCtf CaMfcie COBpeMeH- 
HHe MCTOUBl HCCJie.HOBaHHK VL npoeKTHpOBaHHH, B TOM ^HCJie H CU" 
MyJIHIIHOHHHfi MCTOJl. 

B HaOTonmeM Tpyn;e npejiCTaBjieHH HeKOTOpue npodJieMH nono- 
JIB 30 BaiIHiT CHMyjIHUHOHHOrO MGTO^a RJ1R HCCJie^OBcLHUii BBI^C^H- 
TejIBHHX CHCTeM, B HaCTHOCTH, OIIHCUBaiDTCH TaKHe Bonpocu, KaK 
npoBepKa CHMyjDTu^oHHHx Mo^ejieS, ^ocTOBepHocTB pe3yjiBTaT0B 
CHMyJlfmHH, npHCnOCOÓJieHHe BH^IHCJIHTejIBHOM CHCTeMU K nOTped- 
HOCTHM BUHHCJIHTeJIBHOrO UeHTpa H T.II. KpaTKO OdCyjKJ^aiOTCH 
Taicace rjiaBHue Tpyjjbi, KacaiomnecH HCCJie^oBaHHa CHCTeM npH hc- 
nojiB30BaHHH MeTOfla CHMyjinuHH. 

COMPUTING SYSTEMS ANALYSIS BY A SIMULATION METHOD 


Summary 


The deyelopment of computing systems is still late in comparison i0 
the deyelopment of applications of these systems in yarious fields* * ^ 
order to accelerate this deyelopment the most modern research and d<** 
methods were deyeloped, among others simulation methods. 

Some problems connected with the application of simulation method* , 
the analysis of computing systems are presented in the paper. In p ar * 
ular, such problems as simulation models verification, reliability 
simulation results, and adjusting of a system to the real needs of a 
computing centre, etc,, are discussed, A brief reyiew of the most ^ 
portant results obtained in the application of simulation methods 
analyzing the computing systems is giyen. 
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0 * 6 wi o 

n yc ; no Problemy projektowania i realizacji ela- 
systemów operacyjnych. Przy projektowa- 
r °śla się hierarchiczną warstwową strukturę 
0Qu operacyjnego i następnie warstwy dzieli 
8 f 0r ^ att niejsze elementy - moduły. Wymagany jest 
1 ' izow any opis modułów, na podstawie którego 
2 a P ro & ramowa ć i stosować, oraz opis spo- 
ata no Uczenia w konkretnym systemie. Opis ten 
w Ystarczającą dokumentację systemu opera- 
°kr e *? 0, Wewnętrzna struktura modułów nie Jest 
° na - Mogą one być realizowane przy użyciu 
1u języków programowania. 
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1. WSTĘP 

Współoześnie produkowane i rozpowszechniane systeny opera¬ 
cyjne osiągnęły taki stopień złożonośoi, że ioh poznanie choć¬ 
by w oelu zdobyoia umiejętnośoi pełnego korzystania z dostar- 
ozanyoh przez nie udogodnień przekraoza możliwośoi przeoiętneg 0 
programisty. I tak jak kiedyś brak udogodnień w korzystaniu 
z maszyn narzuoał przeoiętnemu użytkownikowi konieoznośó korzys¬ 
tania z pośredniotwa zawodowego programisty, tak obeonie nadmis? 
lob prowadzi do tego samego. Sytuaoja komplikuje się, gdy użyt- 
kownlk ohoe korzystać w tym samym ozasie z systemów lioząoyob 
wyprodukowanych i oprogramowanych przez różnyoh produoentów lub 
też ohoe po doówiadozeniaoh z jednym systemem zaoząć korzystać 
z innego. Jak trafnie zauważa Cox [4] jedyną wspólną oeohą 
współozesnyoh duźyoh systemów operacyjnyoh jest to, że są one 
ogromne. Do oozywistyoh nonsensów należy zaliozyć np. fakt, że 
języki typu job oontrol language, które w każdej maszynie speł¬ 
niają ten sam oel, a mianowioie wiążą logiozne urządzenia wejó- 
cia-wyjśoia programu z fizyoznymi i mówią o tym jakie programy 
i w jakiej kolejnośoi mają być wykonywane, zaprojektowane cele® 
ułatwienia żyoia programiśoie, są przeważnie skomplikowane, ni 0 
osiągnęły standaryzaoji ozęsto w obrębie tego samego systemu a 
już z reguły są różnie zaprojektowane w różnyoh systemaoh. 

Przyozyną tego stanu rzeozy jest obraz użytkownika jaki wy¬ 
tworzyli sobie produoenoi. Użytkownik powinien z radośoią 
przyjmować to co mu się przekazuje, gdyż wśród dostarozonyoh 
ułatwień są na pewno 1 te, na które liczy. 

Prześledźmy przyozyny i skutki takiego rozumowania: pooząt- 
kowo na skutek ogromnyoh możliwośoi sprzętowyoh potrzeby użyt¬ 
kowników były niewielkie. Skromny dorobek programowy przy P°" 
jawieniu się nowej maszyny mógł być odtworzony stosunkowo nie¬ 
wielkim nakładem kosztów. Ten dorobek programowy narastał wraź 
z rozszerzaniem si£ możliwośoi sprzętowyoh, jednooześnie rosły 
potrzeby, oo z kolei wymagało nowego sprzętu. Pomiędzy użytkowy 
niklem a maszyną stanął system operaoyjny, którego zadaniem j 0fl 
ułatwić użytkownikowi wykorzystanie sprzętu. Ukształtowała 
praktyka, żeby uprzedzająo żyozenia użytkownika dać mu możli- 


i 
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»l e 

^jwięoej środków programowyoh do urzeczywistnienia wszel- 
m °żliwyoh żyozeń. Oozywiście zawsze jednak znajdzie się 


potrzeba, której dostarozonymi środkami zaspokoić nie moż- 
to* ^ nawet te odpowiadająoe potrzebom środki istnieją, 

Pot 828086 0< * na ^ ez *- en * a w ogromnej masie tego właśnie, oo jest 
rzebne i możliwośoi skorzystania z czegoś, co stosuje się 
^ nuiie rzadko, a więc nie ma się biogłośoi w używaniu, są pro- 
^^^yozne. Stosuje się różne środki zaradcze np* w postaoi an- 
t ^nia wysoko wykwalifikowanych programistów speojalnie po 
^ 1 Umieli tłumaozyć język potrzeb użytkownika na język moż- 
^ośoj- systemu. Jest to niezmiernie kosztowne, przede wszyst- 
0 ^ Q ^nak szkoda marnować zdolnych ludzi mogąoyoh wykonywać 
kle bardziej wartościowe prace [4]« 

którzy użytkownicy próbują na własną rękę mniej lub bar- 
^ udolnie modyfikować system, upodabniając go do tych, z 
***1 mieli do czynienia dotyohczas* 




Tak 


więc wyobrażanie sobie czego użytkownik może potrzebo- 


jsst rozumowaniem fatalnym w skutkach< 


^ekiemu rozumowaniu, którego praktyoznym odzwierciedleniem 
O 1 

5 a P. 0S/360, należy przeoiwstawić innet użytkownik powi- 
, a Otrzymać minimalny komplet narzędzi, za pomocą któryoh 
^ - Niczyjego pośrednictwa zbuduje sobie sam taki system ope- 
^dhy, jaki mu najbardziej odpowiada* 

i. ^ s ^gnięoie tego stanu, który praktyoznie będzie oznaozał 
/' w ldao.ie zawodów nro.lektanta i programisty systemów operaoyj- 


oh. 


isL0 ję zawodów projektanta i programisty systemów 
Ole jest realne w bliskiej przyszłośoi. Dążeniem do tego 
jest szukanie metod i narzędzi automatyzujący oh prooes 
ar 2ania oprogramowania (a więo i systemów operaoyjnyoh). 


ł ® dalszej ozęśoi opracowania ohcemy poświęoić nieoo uwagi 
1|r: właśnie metodom i narzędziom. 
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2. BŁĘIDY. LOGICZNE A MOŻLIWOŚCI ZMIAN 

System operaoyjny może być rozpatrywany jako ta ozf^ ^ 
temu lioząoego, która dzieląo instalaoję sprzętową porni?^ 
niezależnyoh użytkowników odpowiada za najlepsze wykorzy 8 * 9 , 
systemu jako oałośoi i jednocześnie za najlepszą obsług? 
go użytkownika. Centralna pozycja jaką zajmuje system °P flj9 . 
ny w systemie liozącym sprawia, że błędy popełnione pr^ ‘ 
projektowaniu lub produkoji rzutują na możliwośoi użytk 5 *^ 
oałego systemu, poważnie komplikująo lub wręoz uniemożl^ 
korzystanie z niego (I^le w [25] str. 71). 


System operacyjny stanowi tę część oprogramowania, 
musi być wykonana w pierwszej kolejności stając się p°d s 
oałego oprogramowania. Nabudowywane na systemie operaoyj* 3 ^, 
oprogramowanie będzie ponosiło konsekwencje błędów popo* 0 *^ 
nych przy wykonywaniu systemu operacyjnego. Z kolei pop* 8 .,: 

nie błędów w systemie operacyjnym staje się praktyozni® 1 

vvi* 

liwe, gdyż oprogramowanie zaakceptowało te błędy i wsze- 1 ' 
dalsze usprawnienia systemu operacyjnego muszą staranni 5 ^ 
błędy przenosić z edycji do edycji. Projektanci system^ j 
racyjnyoh lub translatorów języków programowania, które ^ 
kały się maszynowej realizacji i były eksploatowane, óo s 
znają tę koszmarną sytuaoję. 

. V 

Projekt systemu operacyjnego w stopniu znacznie wyżS" ; 
projekt jakiejkolwiek innej części oprogramowania musi 
niać możliwość nieustannych zmian w systemie w czasie 
użytkowania. Zmiany te dotyozą zarówno dostosowywania 8 ^ s 
do nowych potrzeb użytkowników (których nie można było P 1 t ( 
dzieć) jak i do nowych możliwości sprzętowych (użytków* 1 ^ 
dzie z reguły rozwijał system dołączając nowe urządzeni 5 
wnętrzne, powiększając pojemność pamięci itp«). W skraj 5 ^ ^ 
przypadku, ale i z nim trzeba się liczyć, użytkownik * 
ohcieć dokonać pełnej wymiany sprzętu. 

System operaoyjny, w którego projekcie nie przewidzi 5 
kich możliwości bądź przewidywano ale zagubiono w prooe 5 ^ 
realizacji, można uznać za stracony w przypadku konieozn° 
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2e 


Zla ian, Wprowadzać zmiany do systemu operacyjnego, zawierające- 
w sobie błędy logiczne, jeśli ten system na dodatek posiada 
^ at alną dokumentację, mogą w najlepszym przypadku tylko jego 
^órcy. Nikt, poza twórcami, nie jest w stanie tak zmodyfikować 
^stemu operacyjnego, żeby wprowadzając doń nowe właściwości 
Zaprzepaścić dotychczasowych (a więc zachować całe oprogra- 
1110 Wanię ). Autorzy referatu na własnym przykładzie odczuli, co 
znaczy modyfikować system operacyjny będąc zarówno jego au¬ 
lami (przejście z systemu S041 do S0141 na maszynie ZAM41) 
i będąc w pozycji użytkownika systemu (badania możliwości 
2ni ian w Exeoutive maszyn ODRA System 1J00). Oozywiście wiele 
2al eży od zakresu zmian* Jednak uważamy za mało prawdopodobne, 
^ ftożna było wykazać, że zmiany wykonane w istniejącym syste- 
^ nie powodują nieprzewidzianych błędów. Praktyka potwierdza 
^ as ze zdanie* Jako koronny przykład może służyć 0S/360, którego 
^•°Sika uważana jest za niepoprawną, w wyniku czego często do- 
Warczane użytkownikom nowe edycje systemu zawsze są obarczone 
liczbą błędów (Pyle w [ 25 ] str* 71) • 


elastyczność 

Możliwość wykonywania zmian w systemie operacyjnym bądź w 
^° w olnym programie narwana bywa elastycznością (flexibility) . 
^ w i*ny, że system operacyjny (lub dowolny program) jest elas- 
jeśli jest przenośny (portable) i przystosowalny 
U ^ptable). 

Każdy program jest zaprojektowany do działania w jakimś oto- 
^iu (environment) • Otoczeniem dla systemu operacyjnego jest 
^ 3 te m sprzętowy. Mówimy, że program jest przenośny, jeśli ma 
własność, że może być odwzorowany na różne otoczenia* 

dogram jest przystosowalny, jeśli umożliwia dostosowanie 
80 do potrzeb użytkownika bez zmiany otoczenia. 

Przenośność programu bywa określana jako miara łatwości z 
' Program może być przenoszony z jednego otoczenia do dru- 
6 le So; mówimy, że program jest w wysokim stopniu przenośny, 
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Jeśli ilość pracy (koszt) włożona w przeniesienie programu Je** 
znacznie mniejsza niż praca włożona w wykonanie go od początku* 
Podobnie można określić przystosowalność. 

Główna różnica między przystosowalnością a przenośnością po¬ 
lega na tym, że przystosowalność jest związana ze zmianami 
struktury algorytmu, podczas gdy przenośność jest związana ze 
zmianami otoczenia [3, 18, 26]. 

W wielu publikacjaoh spotyka się określenie niezależności oi 
maszyny (machinę independence), które bywa traktowane bądź ja^° 
synonim przenośnośoi bądź jako określenie własności słabszej 
(wg Goosa [9] wymaga się by program był niezależny od taki 0 * 1 
detali struktury maszyny jak długość słowa, liczba i rodzaj 
jest rów itp.) • 

Bywa też stosowane pojęoie rozszerzalności (extendability) 
używane w sensie zbliżonym do elastyczności (np# [11]), ale z 
reguły odnoszone do różnych konfiguracji tego samego systemu 
sprzętowego (a więc bez wymagania niezależności od maszyny)* 

Przy okazji warto zauważyć, że jakkolwiek stopień trudności 
w uzyskiwaniu elastycznych systemów operacyjnych jest powsze 0 * 1 '’' 
nie dostrzegany, o tyle w wielu publikacjach wyraża się przy¬ 
puszczenia, że uzyskanie systemów operaoyjnych w dużym stopniu 
niezależnyoh od konkretnej maszyny (a więc potencjalnie prze** 
nośnych) jest prawdopodobne, gdyż stosunkowo niewiele żądań 
stawianych systemowi dotyczy bezpośrednio sprzętu, natomiast 
większość sprowadza się do zwykłego przetwarzania liczb, li 0t 
itp# Szacuje się, że w większości współczesnych systemów opo" 
racyjnyoh, 60-70% objętości składająoyoh się na nie programów* 
mierzonej w instrukcjaoh maszynowych jest w istooie niezal© źn * 
od maszyny (por. [ 3 ] i Hendry w [25] str. 64). 

Zanim zajmieny się rozważaniami na temat sposobu w jaki 
można uzyskać system operacyjny w możliwie wysokim stopniu 
elastyczny, spróbujmy określić jakie szczególne cechy różnić 
go od innych programów. 
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Pierwsze: system operacyjny z założenia jako jedyny skład- 
^ oprogramowania musi być związany z konkretną maszyną 
' °nieczność obsługi przerwań, fizycznych prooesorów i pamięci 
lt P.) . 

Po drugie: system operacyjny jako jedyny składnik oprogramo- 
,^ a musi być programem obliczenia współbieżnego [ 2 ] 
J* 8 półbieżne procesy w samym systemie operacyjnym i program 
ez ależ 
®żńe). 


^Półbieżne procesy w samym systemie operacyjnym i programy 
■ bieżnych użytkowników traktowane również jako procesy współ- 


drzecie: system operacyjny musi działać na progra- 

^ Prowadząc gospodarkę pamięcią wewnętrzną i zarządzając 

Rożnymi prooesorami przeprowadza operacje ładowania progra- 
a 

^ ^ A ° pamięoi wewnętrznej, ich usuwania (są wtedy danymi) oraz 
^konywania (przydziału fizycznego prooesora - są wtedy 
;,r °eramami) . 

Wymienione wyżej cechy mogą mieć także inne programy, pod- 

^ ^ Al 

jednak, że dla systemu operaoyjnego są one konieozne. 

^ p ro 0e8 wytwarzania każdego programu obejmuje Jego zaprojęk¬ 
nie i wyprodukowanie (realizaoję maszynową - implementa- 
*'• Obsługi teohnioznej (konserwaoji) [26] , wohodzącej również 
8 ^iad prooesu wytwarzania, nie będziemy tu omawiać. Projekto- 
j i maszynowa realizaoja stanowią zwykle cykl iteraoyjny 
® r8 ńica między nimi jest często trudno uohwytna, ale dla jas- 


^06 

'IWto 


Ci rozważań będziemy mówili o projektowaniu i o produkcji 


0 odrębnyoh ozynnośoiaoh (choćby w tym rozumieniu, że mo- 
.!'j wykonywać różni ludzie) . 


r 2ez zaprojektowanie programu będziemy rozumieli sporządze- 
°Pisu wystarozająoego do tego, żeby można było zarówno pro- 
^ować inne programy z niego korzystające jak i wyprodukować 
Program. 


Me 
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4. JĘZYKI PROJEKTOWANIA I PROGRAMOWANIA 

Związki prooesu wytwarzania systemów operaoyjny oh z języ^* 
mi programowania są oczywiste. 

Najbardziej perspektywiczne wydaje się stosowanie języków 
wysokiego poziomu zarówno przy projektowaniu jak i przy real* 
zacji maszynowej. Najlepiej byłoby, żeby język projektowani® 
i język realizacji były tym samym językiem. 0 truunościaoh J* 
kie pojawiają się przy definiowaniu takiego języka mówi 
J. Olszewski [ 15 ] . 


Na razie nie ogłoszono, że taki język został określony* ^ 
doniesienia, niestety bardzo lakoniczne, że systemy operacyJ 119 
dla maszyn Burroughs (B5500, B6500) są pisane w ALGOL-u 60 z 
rozszerzeniami (Cleaiy w [25] str. 67» Pyle w [ 25 ] str. 71* 
[21] i [5]) • Nie wiadomo, jakie szczególne warunki spełni®^ 
jednocześnie język, system operacyjny i maszyny, które byt? 
projektowano jako całość zarówno przez konstruktorów sprzęt® 
jak i przez konstruktorów oprogramowania. 

Spotkać się można z 5 zasadniczymi podejściami do stosowa®* 
języków programowania do wytwarzania systemów operacyjnych* 


1) Wykorzystanie uniwersalnych języków wysokiego poziomu. 
dejmuje się próby choćby częściowego wykorzystania przy 
twarzaniu systemów operacyjnych takich języków jak ALGOL 
i różne jego rozszerzenia, ALGOL 68, PL/1 itp. [9, 18] • 
budowie małego systemu operacyjnego (0S6 dla maszyny Mod® 
One [24]) wykorzystano język BCPL [ 20 ] do zaprogramowani® 
wszystkiego poza "małym jądrem". Pomijając już fakt, że 93 
tern operacyjny 0S6 jest jednoprogramowy nadmienić warto* 
język BCPL nie narzuca konieczności pisania czytelnych P*° 
gramów. Prawdopodobnie taki system jest bardziej przen 0 ^ 
ny niż rozszerzalny czy przystosowalny do użytkownika. 
Uniwersalne języki wysokiego poziomu ułatwiają uzyskiwani®^ 
przenośnyoh programów jednak jej nie gwarantują automaty-'"^ 
nie. W programach należy oddzielić wyraźnie strukturę 
rytmów od struktur danych, gdyż głównie te ostatnie musz® 
być dopasowywane do nowego sprzętu. 
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Niektóre uniwersalne języki wysokiego poziomu (np. ALGOL 68) 
Pozwalają zapisywać programy obliozeń współbieżnyoh, nato¬ 
miast nie radzą sobie z funkojami związanymi bezpośrednio z 
maszyną (byłoby to sprzeozne z ioh uniwersalnością). Aby 
8 Pnostać takim potrzebom proponuje się niekiedy wykorzysty- 
*anie języków wysokiego poziomu dopuszozająoyoh wstawki w 
3§zykaoh symbolioznyoh. 

2 ^ 

Wykorzystywanie języków wysokiego poziomu zbliżonyoh do ma- 
®zynowyoh. Takim językiem jest np. PL/360. [28]• Języki te 
^ożliwiają m.in. używanie instrukoji maszynowyoh zapisywa¬ 
ny oh w formie wywoływania proaedury. Jednak fakt, że zawie- 
18 Ją np. pojęoia rejestrów rozumianyoh tak samo jak w kon¬ 
kretnej maszynie (dla PL/360 taką maszyną jest IBM 360), 
®kawia pod znakiem zapytania ioh przydatność z punktu Widze¬ 
wa przenośnośoi. Do tej grupy można zaliozyć również ma- 
krogeneratory, które umożliwiają precyzowanie pojęć (ogólni¬ 
kowo określonyoh na pewnym poziomie)na kolejnyoh poziomaoh 
niższyoh w ten sposób, że traktuje się je jako nazwy makro- 
to zkazów, których definioje również zawierają makrorozkazy 
niższego poziomu itd, aż do zejśoia na poziom kodu maszyno- 
®°6o [4]. W tej grupie języków najozęśoiej można spotkać 
języki - efemerydy, zaprojektowane tylko dla jednego przed- 
8 ięwzięoia i stosowane jedynie przez autorów (por. Buxton 
w * [25] str. 72). Języki takie, rzadko dobrze zaprojektowa- 
Przynoszą więoej szkody niż pożytku, gdyż tworząo je 
Upomniano o tym, że język programowania 00 najmniej w ta¬ 
kim stopniu Jak do porozumiewania się z maszyną służy do 
Porozumiewania się między ludźmi, umożliwiając ozytanie i 
^zumienie napisanyoh przez kogoś programów. Uozyć się ta¬ 
kiego języka tylko po to, aby zrozumieć jeden program jest 
°°zywi8tym nonsensem. 

^ Najbardziej powszeohne - wykorzystywanie języków symbolioz- 
(assemblerów) . Najozęśoiej wysuwanym argumentem na 
korzyść jest fakt, że zapewniają najlepsze dopasowanie 
konkretnego sprzętu i uzyskanie najbardziej sprawnyoh 
pr ogramów. Goos [9] trafnie zauważa, że program napisany 
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w języku symbolicznym może mieć wszystkie pożądane właściwo^' 
oi poza przenośnością* Dodajn^, że również czytelność progi* 8 " 
mów napisanych w językach symbolicznych jest minimalna* 
Warto tu jednak zauważyć, że dysponując jedynie językiem 
symbolicznym można zastosować wspomniane wyżej podejśoie, 
uważane za oharakterystyozne dla makrogeneratorów. Autorzy 
referatu przy projektowaniu struktury standardowego system u 
operacyjnego SOS/1300 dla maszyn ODRA - System 1300 [l4] 
finiowali pojęcia wyżrzego poziomu przy użyciu pojęć pozłot 
niższego itd*, z założeniem, że dopiero w fazie kodowania 
(w języku symbolicznym) będzie podjęta decyzja, które defi 11 * 
cje mają stanowić ciała procedur, a które będą bezpośredni 0 
rozwinięte w oiele programu (lub procedury wyższego poziomi* 

Problem działania na programach pozytywnie rozwiązują tylk° 
języki symboliczne lub języki zbliżone do maszynowyoh. Języki 
uniwersalne wysokiego poziomu tej możliwośoi nie dają. Wyją^ 6 ^ 
stanowią języki konwersacyjne ale nie bardzo wiadomo jak do P* 0 
gramowania systemów operacyjny oh można je wykorzystać. 

Tak więc z punktu widzenia przenośności (a więo elastyozno^ 
oi) najbardziej korzystnie przedstawiają się uniwersalne jęztf^ 
programowania wysokiego poziomu. 

‘A 

Często wysuwa się zarzut, że postulująo przenośność system^ 
operaoyjnyoh i w ogóle programów, mijamy się z rzeozywistymi P° 
trzebami użytkowników. Użytkownik przenosząo program do no* 0 ® 0 
otoozenia będzie ohciał go przy okazji poprawić. Możliwe. J 0 ^ 
po pierwsze - zanim go poprawi - może go mieć w nowym otoożenią 
w wersji niepoprawionej i tymozasowo z niego korzystać, po dr ^ 
gie - program zaprojektowany z myślą o przenośnośoi o wiele ** 
wiej jest poprawiać, zwłaszcza jeśli zaprogramowano go w j? 2 # 
wysokiego poziomu. 

Sprawność przenoszonego oprogramowania jest oozywiśoie 6° r '’ 
sza niż projektowanego od nowa dla konkretnej instalaoji, ala 
zawsze istnieje możliwość dostrojenia. Proponuje się np. żeby 
wykorzystywać w tym celu translatory języków programowania 
sokiego poziomu produkująoe programy wynikowe w języku symbo- 
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jjp '^ ak ^' a programy można najdokładniej dopasowywać do kon— 

e ^Hego sprzętu i wymagań. 


,, 0licz ąc uwagi na temat podejścia językowego do konstrukoji 
j^^ 0551 ^ 011 systemów operacyjnych warto odnotować propozycje 

Prz 80 *^ 06 ’ żeby przy °P racow y waniu języka wysokiego poziomu 
^eznaozonego do programowania systemów operacyjnych nie dą- 

Uzyskanla Jednego języka, a raczej wprowadzić język z 
ko 0ma pod J ęzykami (oczywiście wysokiego poziomu), umożliwia- 
P^ 8an ^ e różnych fragmentów systemu operacyjnego w róż— 
ftlr- ^ ęzykacl1 t 26 J • Zwracamy tu uwagę na to podejście, bo właś- 
liw- Pr ° 6ram0Wanie modularne * ° którym będzie dalej mowa, umoż- 
R spełni en i e tego postulatu. 


struktura hierarchiczna 

^ Syg tem 0pera0 yjny przekształca maszynę fizyczną w wirtual- 
Pró r ° 6ram P rz ekształoania maszyny fizycznej w wirtualną jest 
Kramem pisanym w języku tej fizycznej maszyny. 

^ Wyn ika stąd, że ohcąc wprowadzić drobną zmianę, która wyma- 
^ małego stopnia wiedzy o sprzęoie, musimy ozęsto pozna- 
Ca l^ maszynę fizyczną. Maszyny zaś z reguły są opisywane 
ł .0 - Z ° nie Precyzyjnie, przeważnie w języku naturalnym i za po- 
z , Cs Pojęć, które zwłaszoza z punktu widzenia człowieka przy- 
2a Jonęgo do języka programowania wysokiego poziomu są egzo— 
° 2 he» rejestr, przerwanie, obsługa kanału itp. 

^nopoziomowy, jednowarstwowy system operacyjny jest bar¬ 
tą 18510 elastyczny, tzn. że nie bardzo wiadomo jak wiele trze- 
ni - :a zmienić, żeby go przenieść z otoczenia do otoczenia, 
z&ohowując otoczenie zmienić definioję maszyny użytkownika. 

Bt zmienia się, gdy podzielimy system operacyjny na war- 

(layers) tak, żeby warstwa poziomu n określała maszy- 
j 0 ^ r tualną dla poziomu n+1 i wyłącznie za pomocą środków 
i <a ' ar “ozonyoh przez warstwę n-1. Warstwy realizują prze- 
«C ai ° enle maszyny fizyoznej w wirtualną stopniowo. Taką 
'^kturę systemu nazywamy hierarchiczną. 
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Uzyskujemy więo system podzielony na ozęśoi składowe'. 
dział systemu na ozęści pozwala osiągnąć dwa główne cele* 


1. możliwość uzasadnienia poprawności logioznej (i znalezień* 
błędów) na etapie projektowania, 

2. możliwość uzyskania systemu operaoyjnego podatnego na 
ny, elastycznego. 

Wyżej mówiliśny o potrzebie zarówno poprawności jak i el^ 
tycznośoi. Zastanówmy się jaki związek te pojęcia mogą 
z podziałem systemu operacyjnego na warstwy. Nie będziemy 
rozważać w jaki sposób można przeprowadzić dowód poprawności 
programu (a więo i systemu operacyjnego), jest to osobne, 
szeme zagadnienie. Warto tu nadmienić, że mówiąc o popraW^ 0 ^ 
ci programu właściwie mamy na myśli weryfikację naszego 0^ u 
o nim, gdyż naprawdę nie istnieją programy niepoprawne - 
istnieją tylko programy inne niż sobie wyobrażamy (A. Mazur^ 0 
wiczs Problemy programowania*). 

Parnas [17] podkreśla, że dowody poprawności programów ioo6* 
okazać się tak złożone, że poprawność tych dowodów stoi V 0 ^ 
znakiem zapytania. Im prostszy program, tym dowód jego popr^ 
ności będzie prostszy. Jest to argument za dzieleniem prog^ 11 
na części składowe, których poprawność można łatwo udowodni 
i z kolei wykorzystać te dowody przy dowodzeniu poprawności 
łego programu* 


Związek między podziałem systemu operacyjnego na ozęśoi a 
możliwością zmian też widać wyraźnie. Można uzyskać taki V°" ^ 
dział systemu, żeby w celu wprowadzenia zmian przeprojektow^^ 
tylko nieliczne jego części, a pozostałe zostawić nienarus z ° p6 
Zmiany mogą więc mieć lokalny charakter. 

Często wyżej niż poprawność stawia się niezawodność bąd^ 
efektywność (przy czym zwłaszcza efektywność bywa bardzo V^ 


* Materiały na sesję naukową z okazji Roku Nauki Polskiej i XV-leci» 
zesz. 1, Warszawa -1973 • str. 1-29. 
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Łlu i ozęsto nieprecyzyjnie rozumiana) . Łatwo jednak wykazać, 
Ł ° logioznie poprawny system można uczynić niezawodnym i efek- 
żywnym jak również, że nie można tego dokonać w stosunku do 
8 ystemu z logicznymi błędami. Z kolei nieuohronne modyfikaoje 
8 ystemu, w którym nie przewidziano możliwośoi zmian mogą się 
° d bywać tylko kosztem utraty zarówno niezawodności jak i efek¬ 
tywności. 

Zastanówmy się teraz jak przeprowadzić taki podział syste- 
nu °Peraoyjnego na warstwy. 

Jeśli przyjąć za warstwę najniższą tę, która bezpośrednio 
8 tyka się ze sprzętem (stanowi oprogramowanie tego sprzętu), 

* najwyższą - warstwę obejmującą programy użytkowników 

samego użytkownika w wariancie konwersacy jnym) , to każda 
W ^rstwa opisywana jest w kategoriach funkcji realizowanych 

warstwy niższe. Czyli można powiedzieć, że poszczególne 
tratwy wprowadzają usprawnienia programowe wykorzystywane w 
^rstwach wyższych [26] . 

Przykładem tak zaprojektowanego systemu jest system opera- 
"THE" [8], któxy zrealizował Dijkstra na maszynie Elec- 
**°logi ca X8. ściśle hierarchiczna struktura jaką przyjmuje 
jest zaprojektowana głównie z myślą o tym, żeby łatwo 
udowodnić poprawność systemu. 

Rozważa się sześć warstw (poziomów): 

®*®*wa 0 - w tej najniższej warstwie w powiązaniu z obsługą 

przerwań zegarowych realizowany jest przydział fi- 
zyoznego procesora jednemu z procesów realizowa¬ 
nych w warstwaoh wyższych. Powyżej tego poziomu 
nie istnieją prooesory fizyozne. 

tratwa 1 - przekształoa dwupoziomową pamięć fizyczną (we¬ 
wnętrzna i bębnowa) na pamięć jednopoziomową. Po¬ 
wyżej tego poziomu operuje się wyłącznie pamięoią 
wirtualną. 
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Warstwa 2 - przekształoa fizyozną konsolę (monitor dalekopis 0 ' 
wy) w niezależne konsole konwersaoyjne przypisali® 
do każdego z procesów. 

Warstwa 5 - przekształoa fizyozne urządzenia wejśoia i wyjóoi* 
. w strumienie wejśoiowe i wyjśoiowe. Liczba fizy° 2 ' 

nyoh urządzeń przestaje być istotna na poziomaoh 
wyższych. 

Warstwa 4 - obejmuje prooesy niezależnyoh użytkowników. 
Warstwę 5 ~ stanowi operator. 

Przyjęta struktura umożliwia operowanie pojęciem procesu 
sekwencyjnego, począwszy od poziomu 1, umożliwia też lokali 20 ' 
wanie w obrębie warstwy ewentualnych modyfikacji sprzętowych# 
Np. warto zauważyć, że zmiana liczby fizycznych procesorów t?' 
dzie wymagała przebudowy jedynie warstwy O [7]« Według podot" 
nych zasad konstruowany był również system operacyjny RC 400® 
[2, 19] . 

Liczba warstw w systemach hierarchicznych nie konieozni® ^ 
si być taka jak u Dijkstiy. Często przekształca się w wirtua^ 
zarówno fizyczne procesory jak i pamięci w obrębie tej samej 
warstwy - mówi się wtedy z reguły o "bardzo małym jądrze" n^P* 
sanym w kodzie maszyny. 

Przykładem takiego systemu może być system operacyjny 
[12, 13] realizowany na Uniwersyteoie w Manchester dla 
maszyn (na obecnym etapie: maszyny MU5 i ICL 1905E). W syst 0111 ^ 
tym tylko warstwa najniższa (nazywana tu Supervisor Supervi 0 ° 
zrealizowana jest na maszynie fizycznej. Cała reszta stano** 

■no' 

oddzielne programy nazywane Supervisorami działające już na * 
ziomie wyższym (korzystające z własnych maszyn wirtualny oh) 
i definiujące nowe maszyny wirtualne dla różnych klas użytk offr 
ników (będą to np. Supervisory: Batch Job Control f Intera 0t " 
ive Job Control f Iteservation System itp*) . Programy użytko* 0 * 
ków znajdują się oozywiśoie na jeszcze wyższym poziomie. 

W przypadku struktury hierarchicznej istotne jest aby 
warstwa mogła tyć opisana wyłącznie przy użyciu pojęć wars 1 ^ 
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r 2p0 ® redn i° niższej - a nie dalszych. Oczywiście niektóre 
^ '°ia przenoszone są przez poszczególne warstwy bez zmian, 
8odzą c się na koszt realizacji takich jałowych przejść mo- 




*>l* 


ustrzec od przykrych błędów, które powstają przy ko- 


C2 nośoi sięgania do warstw dalszych. 


l'a> 


Qq 


a konieczność pojawia się w systemach zaprojektowanych 

Prawd* 


t ’’ Ja warstwowo » lecz nie konsekwentnie .Istnie ją takie sys- 
I °P®racyjne gdzie (jak np. w SO 141 maszyny ZAM 41) w tej 

g " w arstwie korzysta się z różnyoh poziomów abstrakcji 

Ł ' C2 4oyoh ty oh sanych urządzeń zewnętrznych - powstaje 

M* 


y taożliwość konfliktów, trzeba budować sztuczne zabez- 
C2 ®Qia itd. 

dęlibyśmy wyrazić przekonanie, że systemów bez wyraźnej, 
^ wowoj struktury nie da się dobrze opisać. Nie można bo- 

u 

V,.. . uzn ać za dobry opis ozegoś, co jest w istocie katalogiem 
c lwości z różnyoh poziomów - obszernym i nieczytelnym. 


chi 


10 jektowanie i programowanie systemu o strukturze hierar- 

CZGe 3 najlepiej byłoby przeprowadzić przy użyciu języka pro- 
Ui>al r 


^ inego wysokiego poziomu. Jak wiadomo są kłopoty z uzyska¬ 
ją talt iego języka przydatnego do programowania systemów ope- 
Wszelkie przybliżenia są jednak racjonalne. Toteż 


Realizacji maszynowej danej warstwy można uznać za obo- 
^ ^ byleby uzyskana na styku z warstwą wyższą maszyna wirtu- 

t2Q ozywiście miała założone właściwości. Można mówić o 
oj Rodzajach opisu warstwy: dla użytkownika - czyli defini- 
Daszyny danego poziomu wyrażona w pojęciach tego samego po- 
^ oraz dla wykonawcy - definicja maszyny danego poziomu 
a ^°ha w pojęciach poziomu bezpośrednio niższego. 


1,01)0 LARN OŚĆ 

^ Oll lamość można traktować jako uogólnienie warstwowośoi. 

systemu można prowadzić warstwowo (modularyzaoja plo¬ 
mbo nie dzieląo systemu na warstwy wyodrębnić w nim 
o różnyoh funkojonalnie właściwościach (modularyzaoja 
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pozioma). Praktycznie - zwłaszoza przy dużych systemaoh podzi* 1 
.jest prowadzony i w pionie i w poziomie, tzn. warstwa dzieło* 1 * 
jest na moduły. 

Definicja modułu zależy zarówno od tego, po co się dzieli 
jak-i od tego, jak się opisuje strukturę. Parnas [17] określa 
moduł po prostu jako część wskazaną przez opis systemu. 

Potrzebę podziału systemu na warstwy wykazaiiśny - warto 
również zauważyć, że podział warstwy na mniejsze moduły oz? 0 * 0 
pozwala zastąpić potrzebę przeprogramowywania oałej warstwy ^ 
mianą jednego modułu. 

Rozmiar modułu ustala się zwykle na wyozuoie — bo kryteria 
są sprzeczne: im więcej modułów - tym łatwiejsze zmiany, al® 
z kolei tym więcej powiązań między nimi, co może oznaczać P°' 
trzebę większej liczby przesłań informaoji np. między warstwa' 
mi. 


Moduł jako jednostka projektowania musi być opisany. Opi 0 
modułu ogólnie też trudno wyrazić. 0 ile w przypadku warstw 
rzecz jest pojęciowo prosta, o tyle w innych podziałach trz 0t * 
sformułować ostrożniejsze postulaty. Potrzebne są dwa opisy 
dułu: jak z niego korzystać i jak go zbudować. Zdaniem Parn® 0 * 
[16] opis modułu powinien zawierać absolutne minimum wiedzy* 
wystarozająoe do tego, aby moduł zbudować i aby z niego skor 2 ^ 
stać. W szczególności opis modułu nie powinien podawać jeg° 
struktury wewnętrznej. 

Często uważa się, że moduły mogą być opisywane w języku 
turalnym. Podejście takie nie wydaje się słuszne. Według P ftir 
nasa [16] opis modułu powinien być na tyle sformalizowany* 
żeby można go było poddać maszynowemu testowaniu ( np. czy 0 P* 
suje wszystkie możliwe stany modułu), a w każdym razie przeP^ 0 
wadzić rozumowanie pozwalające na podstawie samych opisów *7 
zaó poprawność logiczną systemu# 

Niekiedy modulamość rozważa się jedynie na etapie proje 1 ^ 
Tymczasem istotną zaletą modulamośoi jest, że części syste® 1 * 
wyróżnione w projekcie zachowują tożsamość w gotowym syste®* 0 


k 
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konsekwencji dokumentaoja projektowa - sformalizowany opis 
°°<3ułu przez oały czas działania systemu może pozostać jedynym 
^kumentem. Czynnikiem ułatwiającym opis i korzystanie jest 
st &ndaryzacja, a więo traktowanie modułu jako pewnego rodzaju 
j^jemnika (być może jest kilka typów pojemników różniących się 
i2 tałtem) , który można w typowy sposób zestawiać z innymi. 

Rozważmy przykładowo, że moduł miałby kształt procedury np. 
8 ensie PASCAL-a [29] . Jeśliby wśród parametrów wywołania 
" hiał ustalony parametr typu boolean wskazujący np. czy za- 
° n czyć proces (teiminate process[2]) czy też nie, to ten sam 
°^ u ł mógłby być w zależności od sposobu wywołania albo zwykłą 
^ooedurą albo programem procesu sekwencyjnego. 


°Pis systemu operacyjnego sporządzony w języku wysokiego po- 
*^°mu byłby opisem jego poszczególnych warstw zrealizowanych w 
rni ie procedur, przy czym, im głębiej zanurzona byłaby dekla- 
' c ja procedury - tym bliżej sprzętu leżącą warstwę opisywałaby. 


^ Moduł może być traktowany jako operacja obliczenia (współ- 
®ćnego lub sekwencyjnego). Z kolei modułowi odpowiada obszar 
^^ięoi wymagany do jego działania. Będąc operacją (a więc i 
^^ G zeniem) moduł pozostaje jednocześnie segmentem danych, 

0t e można przenosić z miejsca na miejsce (co spełnia wymaga¬ 
ją 6 b y można było traktować programy jako dane i odwrotnie). 
lakujemy w ten sposób właściwość dostępną jedynie na poziomie 
'^yka symbolicznego (zawartość każdego miejsca pamięci - tu: 
^bł » może być traktowana zarówno jako operacja jak i jako 

V). 


Konsekwentnie wprowadzając modularność można uzyskać system 

^ 0( ^tny na zmiany. Przy czym w znacznym zakresie zmienność tę 

^kuje się przez tworzenie bibliotek modułów pogrupowanych 

^twami, z których można składać różne systemy dla różnych 
P0+: 

rz eb użytkowania (warstwy wyższe) oraz dla różnych rozsze- 
' n i być może głębokich zmian sprzętu (warstwy niższe) , Moż- 
tównież mając moduły w różnych wykonaniach (np, krótsze ale 

**‘01 

^iejsze, dłuższe ale szybsze) uzyskiwać systemy różne w sen- 
e fektywności czy niezawodności. 
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Realizacja maszynowa modularnego systemu operacyjnego może 
przebiegać w ten sposób, że moduły będą pisane i testowane 
(ze względu na zgodność z opisem) w dowolnej kolejności, a 
więc w szczególności na raz przez większą grupę programistów* 
Dopiero kompletowanie systemu musi przebiegać warstwami - 
najniższej poczynając. 

Skoro struktura wewnętrzna modułu nie jest precyzowana w 
jego opisie, istnieje dość duża swoboda w stosowaniu środków 
programowych przy jego wykonywaniu. Różne moduły można zapr°" 
gramować wykorzystując różne języki programowania. 

Zastosowanie języka wysokiego poziomu do wyprodukowania 
dułu automatyzuje jego produkcję dla różnych systemów sprz ^^ 0 
wych* 

Na końcu zostaje do omówienia problem warstwy najbliższej 
sprzętu (definiującej proces). Można tylko wyrazić życzeni® 
by była jak najmniejsza. Nie znamy żadnego zadowalając ego °P 
su struktury warstwy 0. Musi być wyrażona za pomocą pojęć 
szyny fizycznej, a te dla różnych maszyn są bardzo różne. 

Wydaje nam się, że przynajmniej ta warstwa musi być zrea A 
zowana od nowa przy przejściu z maszyny na maszynę. Produkc^ ^ 
tej warstwy można zautomatyzować jedynie przy pomocy pro je 
tów sprzętu, jak to ma miejsce np. u Burroughsa [ 5 ]. 


7. WNIOSKI KOŃCOWE 

Staraliśmy się wykazać, że jakkolwiek brak języka wysoki®^, 
poziomu do pisania systemów operacyjnych jest przeszkodą w u 
kaniu pełnej automatyzacji wytwarzania systemów operacyjny 011 
w ogóle a elastycznyoh w szczególności, to możliwe są rozwiń' 
nia częściowe, pozwalające uzyskiwać pożądane efekty nawet 
przy braku takiego języka. 


Najbardziej obiecującym podejściem jest nadanie system° tfi 
operacyjnemu na etapie projektowania konsekwentnej hieraroh^^^ 
nej struktury warstwowej, umożliwiającej zarówno wczesne wy 


L 


2e? 


^Pec. 
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^ błędów projektu, jak i szerokie modyfikacje zarówno w za- 
e słe sprzętu (warstwy niższe) jak i w zakresie sposobów użyt- 


k* 

tr 

^ Wan ia (warstwy wyższe) • 

bzieiąęj warstwy na dające się funkcjonalnie wyodrębnić frag- 
() Uzyskujemy możliwość łatwiejszego modyfikowania warstwy, 

8u jąc warstwy oraz ich elementy (moduły) w sposób możliwie 
Jrffi alny uzyskujemy już na etapie projektowania dokumentację 
^ wystarczająco precyzyjną zarówno do tego, by elementy 

Skonać, jak i do tego, by móo się nimi posługiwać. 


*lw 8 

60 


mu 


^ 0a ZGzególne moduły można odwzorowywać w konkretnym syste- 
a Przętowym za pośrednictwem różnych dostępnych i najwłaś- 
2 ych narzędzi programowych (w tym również języków wysokie- 
^°ziomu), mogą być wykonywane równocześnie przez różnych 
Kfamistów, co przyspiesza wykonanie całości systemu. 

^ gotowych modułów można szybko składać różne wersje syste- 


°P 0 racyjnego, który można usprawniać (podnosić efektywność) 


2 wymianę poszczególnych modułów na nowe, specjalnie eta- 
n le zaprogramowane, co jednak wobec lokalności zmian odby- 
U 8 *ę może bez większych zakłóceń w działaniu systemu. 

^sleży sądzić, że jeśli moduły warstw pośrednich będą zapro- 


2 *i 


kowane w języku wysokiego poziomu, to nawet przy radykalnych 


^ '^ach sprzętu (przeprogramowanie warstw niższych) oraz dale- 
^^cych zmianach sposobów użytkowania (przeprogramowanie 
t3 tw wyiszyoh) będą mogły być wykorzystane w zmienionym sys- 

s,, 


Wejście to umożliwia praktyczne przygotowanie oprogramo- 
r ' ' przyszłych systemów liczącyoh, o których sprzęcie 

sposobach użytkowania ma się tylko bardzo ogólnikowe wy¬ 
śnią. 

A w ięo nie znając uniwersalnego sposobu rozwiązywania tak 
L .,,° ŹOn ego problemu jakim jest automatyczne wytwarzanie syste- 
p 19 °Peracyjnych, znajdujemy praktyozne przybliżenie uzyskane 
y < ‘ %2 Podział procesu wytwarzania na odrębne etapy: projektu 
‘“Czynowej realizacji z jednej strony, a z drugiej - przez 
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podział samego produktu na ozęśoi, z których każdą można wy** 5 ' 
czająco precyzyjnie opisać i wystarczająoo łatwo wykonać. 

Okazuje się, że w ten sposób można wskazać również te P 1 ’ 0 '’ 
bierny, których rozwiązania nie może zaniechać poszukiwany ^ 
zyk programowania systemów operacyjnych, jeśli ma stać siS ^ 
jedynym narzędziem, pozwalającym użytkownikowi być sam na 6 ^ 
z maszyną i kształtować ją według swoich potrzeb i upodobań* 


UWAGI DOTYCZĄCE LITERATURY 

W opracowaniu wykorzystaliśmy wiele publikacji, z któi^y 0 * 1 


t<! 


nie wszystkie były cytowane wprost. Chcemy zwrócić uwagę 
które naszym zdaniem są istotne. 

Najszerzej zagadnienia wytwarzania oprogramowania potraf 
wane są w materiałach na temat inżynierii oprogramowania 
[22, 23] ♦ Cenne uwagi na tematy związane bezpośrednio z P* 0 
ma tyką opracowania zawiera praca W.M. Turskiego [26] • 




Literatura dotycząca wytwarzania elastycznych programów * 
reguły odnosi się do programów użytkowych, sekwencyjnych i 
no oddalonych od konkretnego sprzętu. Warto tu odnotować ^ ^ 
cza pracę Poole'a i Waite'a [18] (zaopatrzoną zresztą w ob s 
ną bibliografię) oraz Browna [3]* Natomiast problematyka 0 ‘ , 
tycznyoh systemów operacyjnych nie jest zbyt szeroko przc d0 ^ 
wiana w literaturze. Cox [4] formułuje wiele ogólnych uwag 
temat niezależności systemu operacyjnego od sprzętu, Lamp 000 
[li] oraz Stoy i Strachey [24] przedstawiają swoje pogląd 
temat budowy takich systemów. 




ró& 


i*' 


Problematyką modulamości zajmuje się wielu autorów, 
głównie w odniesieniu do programów użytkowych. Można tu 
wskazać prace: Dennisa[6], Pamasa [16, 17], Judda [10] • ^„u 

kłady systemów operacyjnych modularnych można znaleźć w P 1 ® 
Morrisa [12, 13], Wichmanna [ 27 ] , Bertina [i ]. 
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nPOrPAMMHPOBAHHE OIIEPAUKOHHhK CMCTM 




npeflOTaBjiHDTCfl npoÓJieMti ripoeKTupoBaroiH h peara- 
to- 15 ^Kmc onepaimoHHux chctom. B npoeKTe onpeaejweTOH 
K.Ą-.™ nie CKaH cjiOHCTaH cTpyKTypa onepaunoHHofl cucTeMH, ojioh 


TQ Poa 


pa3nejiHDTOH 3aTeM Ha MeHBnnie nacra - Monyjra. toi 


MOflyJiett H HX HCI10JIB30BaHHH H60(5X0flHM0 UaTB HX 

4 Ko* 506 QaHCaHHe * a Tanae onucamie cnocoóa hx odBejjiHeHHH 

JS^^PeTHyK, OHCT6NQT. 3TO OHHCaiffle HBJIH0TCH HOCTaTOHHOt flO- 
HTai ®ea onepaujiOHHofi chctonih. 

^^PeHHee CTpo®HH6 Monyjiett ne onpenejineTCH. Monyjm mok- 
^ Jr PaMMHpoBaTB npn Hcnoju>30BaHini pa3Hnx h3Hkob nporpaM- 



P 80GRAMMING OK OPERATING SYSTEMS 



(i 

P resents some problems of designing and impleoentation of 
\i H o* °P®rating Systems* In design stage hierarchical layered struc- 
^ ^ * n °perating system is defined. Łayers are divided into smaller 
* 0< *ules. Formalized modules specifications are needed for their 


ta ^i°n and application as well as linkage specifications to 
'* fuli actual operating system. Such specifications mention 
tt ^ s0 sufficient system documentation. " 


mentioned 
Internal strućturę 

*> 0 - e « is not defined* They may be implemented by means of differ- 
Sraaming languages* 
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opracowania jest próba odpowiedzi na py- 
<i ^ acz0 8° języki proceduralne w ich obec¬ 
ny ^° st aci f a nawet w postaci projektów specjał- 
ayg^^y^lanyoh dla opisu poszczególnych części 
Px*Q»! mu °P e racyjnego f nie służą jako języki ich 

bramowania. 


Spis treści 

1% Wstęp 

Sienne lokalne i globalne 
procesy równoległe 
s * PR2 ^OZIAŁ procesora 
• Zakończenie 


1 . 


Wsjęp 


i>ta 


Od 


dawna próbowano i nadal próbuje się mierzyć wydajność 


v Programisty liozbą rozkazów, z których układa on program, 
^ Jednostkę ozasu. Nie liozy się przy tym rozkazów, które były 
0 kreślone, a tylko takie, które pozostały w programie 
^.J&8 o sprawdzeniu i uruohomieniu. Przy takim sposobie ooeny 
Qy korzystnie wypadają oi, którym przypadło układać programy 
^^kie. Okazuje się bowiem, że wysiłek intelektualny włożony 
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w ułożenie, testowanie, poprawianie tzn. wszystko to, oo się 
nazywa uruohamianiem programu, nie jest proporcjonalny do jego 
długości. Im dłuższy program, tym wydajność, nawet tego samego 
programisty, mierzona liczbą rozkazów na jednostkę czasu, jest 
mniejsza. W dziedzinie programowania systemów operacyjnych wy¬ 
dajność ta w miarę wzrostu programów spada jeszcze szyboiej, 
niż w innyoh dziedzinach. 

Mógłby ktoś zauważyć, że w takim razie należy długi program 
rozbić na kilk^ lub kilkanaśoie krótkich, a jeśli te krótkie 
też są za długie, to trzeba rozbijać dalej. Uwaga o tyle nio 
trafna, że nie ma sensu rozkładać na kawałki program u « 
i to sprawdzonego i '•chodzącego”. Programista dostaje przecie^ 
do rozwiązania problem. Program jest rozwiązaniem teg° 
problemu. Należy więc próbować rozbić na części problem, a ni 0 
jego rozwiązanie. Przeoiwnie, prograny, które będą rozwiązani 0 " 
mi problemów ozęśoiowyoh, należy potem złożyć w jeden, stano¬ 
wiący rozwiązanie całego problemu. 

Powyższe jest w sposób oozywisty słuszne w odniesieniu do 
każdej, bardziej skomplikowanej działalności, a nie tylko do 
programowania. Jednakże w dziedzinie programowania podejśoi 0 
takie zyskało nawet swoją nazwę, a mianowioie nazywa się pr°" 
gramowaniem strukturalnym. Lecz nawet wtedy, gdy nazwa ta 
jeszoze nie była w użyoiu, strukturalne podejście do programo¬ 
wania było cechą dobrego programisty* . Leżało również u pod¬ 
staw dążeń w kierunku języków programowania tzw. wysokiego P°" 
ziomu. Bo przeoież zdania złożone, procedury ozy funkcje były 
i są programami, stanowiącymi rozwiązania ozęśoiowyoh proble¬ 
mów, a złożenie takioh części w jeden program było (i jest) 
dokonywane automatycznie przez kompilator danego Języka. Juś 
z tego widać, że język wysokiego poziomu jest istotną pomooś 
w strukturalnym programowaniu. Oczywiśoie, Język taki nie na¬ 
rzuca struktury programuj można w każdym z nich układać takż 0 
zgoła niestrukturalne programy. Struktura programu musi wyni^" 
nąć ze struktury problemu, a rolą programisty będzie ułożyó 

* Materiały na Sesję Naukową z okazji Roku Nauki Polskiej i XV-lecia 
IMM, A. Mazurkiewicz - "Problemy programowania" (oprać, wewnętrzne 
IMM) . 
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pogram, któiy tę ostatnią możliwie dokładnie odzwierciedli. 

„ "J^nak nie wszystko, należy togo dokonać tak, aby każdej 
^strukturze" problemu odpowiadała odpowiednia "podstruktu- 
P r ogramu oraz by mogła ona być układana, sprawdzana i uru- 
iana niezależnie od wszystkich tyoh samyoh czynności odno- 
się do Inny ch "podstruktur" tego samego programu. Po- 
J ' 8 2y warunek nie może być spełniony bez posługiwania się 


^ — wysokiego poziomu. Bez niego bowiem trudno byłoby mó— 

0 hiezależaym traktowaniu "podstruktur” tego samego progra- 
* takim przypadku ausielibyśmy z góry przewidywać wiołkoś- 


^ P°8zozeg6inych ozęśoi programu, ioh rozplanowanie w parnię- 
^•^sposób przekazywania danyoh z jednej ozęści do drugiej i 
8 tym podobnych rzeczy. 


t Jea nakże mając nawet do dyspozycji język wysokiego poziomu 
kompilator nie możemy problemu uważać za rozwiązany. 

„ Ułożony strukturalnie powinien być poprawny nie tylko 

^ Niesieniu do reguł gramatycznych danego języka, leoz rów- 
^ 8 Pełniać szereg warunków wynikająoych z tego, oo vvyżej 

P° w iedziane. A więo powinien mieć postać pewnej hierar- 
^ Programów (procedur, funkoji) tak skonstruowanej, by na 
81 jej poziomie można było rozważać i w pełni rozumieć "oo 
^ Programie dzieje" bez konieczności rozważania przy tym 
^ to dzieje", czyli bez zagłębiania się w niższy po- 
V Ą ‘ k 6«y na pewnym poziomie struktury programu chcemy roz- 
4 , 56 "jak się to dzieje", wtedy powinien wystarczyć tylko je- 
m ^fok w dół", a więo rozważenie, "oo się dzieje" na pozio- 
^ Q 2pośrednio niżej. 

J* 0 * "oo się dzieje" na jakimś poziomie, nie powinno również 
od tego, co jest. na wyższyoh poziomaoh. Innymi słowy 
V 6<iui?a lub funkcja powinna być sprawdzalna w dowolnym kon- 
W 0i «» tj. niezależnie od tego, przez którą inną będzie wy- 

^tywana. 

z kierunków, w jakioh następuje rozwój języków pro- 
V ° V,ania * Odpowiada dość ściśle dążeniom, o których była 
'Wżej. W wielkim skrócie kierunek ten można wyrazić jako 
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ALGOL—PASCAL-PEARL [5» 6, 7] , przy ozym PKAHL (Program 
ation and Refinement Language) jest na razie tylko projekt®®' 
jakkolwiek w dużej ozęśoi zrealizowanym i sprawdzonym. 

Z opisanym wyżej sposobem programowania związane są nadzi r 
je zarówno na to, żeby wysiłek potrzebny do ułożenia progr® 11111 ^ 
był proporcjonalny do jego wielkośoi, jak też na to, by px°&'' 
stanowił swoją łatwo ozytelną dokumentaoję. 


W dziedzinie systemów operaoyjiyoh sytuaoja, i to w obu w , 
mienionych aspektach, wygląda, jak wiemy, bardzo źle. Do z ap ^., 
gramowania takioh systemów potrzebni są najwyższej klasy ®P° ' 


liści i całe lata ich pracy. Zaś napisane i uruchomione 
my nie mogą być traktowane jako łatwo czytelna dokumentaod a ^ 
temu. Wobeo tego powstają oddzielne opracowania, które, i 6 * 

1 


stanowią pełną dokumentację, to są bardzo obszerne i trudno 
nich cokolwiek znaleźć* 


Zatem wydawałoby się, że programowanie strukturalne 2 

rzystaniem języków wysokiego poziomu powinno mieć szczegół* 10 

powodzenie w tej dziedzinie. Jednak tak nie jest, po piei^ s2!0 

dlatego, że programy napisane w takich językach uważa j 

* 

nieefektywne w porównaniu z programami ułożonymi ręcznie, * , 




system operacyjny ma być zbiorem programów możliwie najef 0j ^ 


te$ 

niejszyob (m.in. najszybszych), a po drugie, struktury sy s ^ 


operacyjnych nie dają się w sposób bezpośredni i prosty 




wać na odpowiednie struktury programów napisanych w obecfl 


'J 


używanych językach. Jakkolwiek na temat pierwszej grupy P r: 




\ ef 


takiego stanu rzeczy można wieść długie dyskusje - co 3 e0t> >M 
sze: o zs sjyb3ze ułożenie niezbyt efektywnego programu, 
bardzo mozolne układanie programu, o którym też nie wiad 0 ® 0 ’^' 
ozy będzie najefektywniejszym z możliwych - to druga grup® ^ j 
ozyn stanowi wg autora, istotny problem wymagający przynaj 11111 
prób rozwiązania. 


Na niektóre aspekty tego problemu chcemy zwrócić uwagę " . 
dalszym ciągu referatu. Do pełnego zrozumienia krótka 
temat pojęoia deklaracji: otóż deklaracje będą rozumiane . 
ko - w tekśoie programu są to odpowiednie jego kawałki o k* 0 
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zmienne, prooedury i funkoje "ważne” w danym bloku (pro¬ 
kurze lub funkoji) , natomiast podozas wykonywania programu 
•Leny mówić o dokonywaniu deklaraoji lub deklarowaniu zmien- 
prooedur i funkoji. W przypadku zmiennej będzie to pewna 
^ 9ta °da na pamięoi, polegająoa na wydzieleniu odpowiedniej 
pamięoi oraz stowarzyszeniu z nią nazwy tej zmiennej. 

^ oozywiśoie przyjąć, że wraz z zakońozeniem wykonywania 
^80 bloku (prooedury lub funkoji) następuje operaoja odwrot¬ 
ni! zwolnienie zajętej dotyohozas ozęśoi pamięoi. 


‘ ZI &ENNe lokalne i globalne 

^ Z Przedstawionej we wstępie ogólnej idei programowania struk- 
ta lnego wynikają pewne praktyozne wnioski odnośnie tego, jak 
5 a< iać programy - m.in. nie korzystać z możliwośoi deklarowania 
^Unyoh globalnyoh, ozy, innymi słowy, nie traktować żadnyoh 
l6r myoh jako globalnyoh. Zamiast tego należy posługiwać się 
^ Piżmom przekazywania parametrów — wówczas będzie spełniony 
9 tu hek, by prooedura lub funkoja była niezależna od tego "00 
* ^leje" na wyższym poziomie, a więo sprawdzalna w jakimkol- 
0>v kontekście. Zauważmy, że jakkolwiek w ALGOL-u każda zmienna 
4 9 ^6 traktowana dwojakoi lokalnie na tym poziomie, gdzie 
,, r zdeklarowana, i globalnie na poziomach niższych, to 
. ‘^CAL-u many już pewne ograniozenie, 00 do korzystania ze 
^ ‘ eil byoh globalnyoh; podstawianie na zmienną globalną jest 
" kowane jako błąd formalny i wykrywane podozas tłumaczenia 
Ebiciu, w ten sposób unikany tzw. efektów ubooznych działania 
^ jQ edur lub fu nk oji - Natomiast w PEAHL-u w ogóle pojęcie zmien- 
i 5 ^obalnej nie istnieje; wszystkie zmienne są lokalne, a 
V 8 ' 1 !! mają być dostępne na niższyoh poziomach, to tylko jako 
^try. 

s Władaj ąo program w którymkolwiek z trze oh wymieniony oh ję- 
- ^ hależy wiedzieć, że podozas wykonywania tego programu 
d 9n ne będą "powoływane do żyoia" w momenoie ich deklaraoji, 
U^ Btę PUje przy rozpoczęciu wykonywania odpowiedniego bloku 
^Cal-u - prooedury lub funkoji, w PEAHL-u - operaoji), na- 


L 



162 


Jacek OLSZEWSKI 


tomiast "kończą swój żywot", gdy końozy się wykonywanie bloku, 
w którym zostały zadeklarowane. To samo odnosi się do związ¬ 
ków pomiędzy parametrami formalnymi i aktualnymi procedur lub 
funkcji# Określenie tyoh związków następuje pr^p wywołaniu 
prooedury lub funkoji, natomiast gdy wykonywanie jej kończy 
się, wtedy "ustaje" również jakikolwiek związek pomiędzy pa^" 
metrami formalnymi i aktualnymi. 

Z drugiej strony wiadomo, że w systemie operacyjnym mamy 
procedury działające na zmiennyoh, któryoh "ozas życia” jes^ 
znaoznie dłuższy niż ioh wykonywanie, a ponadto zmienne te n ie 
powinny być dostępne nigdzie poza tymi procedurami. Zatem by*°" 
by błędem zarówno umieszozać ich deklaraoje w oiałaoh owych 
oedur, czyli traktować je jako lokalne, jak i deklarować je n * 
jakimś wyższym poziomie, a w owy oh prooeduraoh działać na ni° n 
w postaci parametrów. Wtedy bowiem byłyby one dostępne rów¬ 
nież poza tymi procedurami# 

Język AlAtOL 60 w swoim wydaniu wzorcowym (patrz Naur [5]) 
umożliwia co prawda rozwiązanie powyższego problemu w sposób 
bardzo prosty. Mamy w tym języku zmienne typu own , deklarowa¬ 
ne lokalnie, któryoh "ozas życia” jest tak długi, jak długo 
trwa wykonywanie całego programu, w którym te zmienne występu 
ją. Jednakże nie bez powodu wiele kompilatorów [ALGOD-u skonst** 0 
owano tak, że zmiennyoh typu own nie "tolerują". "Tolerowani 0 
takich zmiennyoh wymaga bowiem traktowania deklaracji, a pX*2?" 
najmniej deklaraoji typu own* statycznie. Deklarowanie to ni 0 
może odbywać się wtedy, gdy następuje wejśoie do odpowiedni 0 ^ 0 
bloku, ozy wywołanie prooedury lub funkoji. Musi ono odbywa^ 
się w fazie tłumaczenia programu, a najpóźniej w momencie i e &° 
zainiojowania* To zaś narzuca dość kłopotliwe ograniczenia 
na gospodarkę pamięcią; nie może ona być wtedy w pełni dyna¬ 
miczna. 

Poza tym samo wykorzystywanie zmiennyoh typu own nas trę 
pewne trudności, ponieważ przy każdym wejściu do bloku, w 
rym one są zadeklarowane, musi następować sprawdzenie, ozy 111 
ją one wartości, ozy też jest to wejśoie pierwsze, przy któr^ 15 
należy im nadać wartości początkowe. 
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Powyższe wywody mogą także służyć jako odpowiedź na pytanie, 
J^ozego w nowszy oh językaoh programowania nie mamy- zmienny oh 
■ypu own. a W ięo nie możemy również rozwiązać problemu zmien- 
które "żyją" dłużej niż procedury nimi operująoe, aozkol- 
niedostępne są poza tymi prooedurami. Propozycje takiego 
1 J2w iązania podał Hoare [ 4 ]. Proponuje on mianowioie, by takie 
^ e niiQ i prooedury na nioh operująoe ująć w pewną oałość i po~ 
jnktować jako nową konstrukoję językową, którą nazywa monito- 
* I# * ^orma ta miałaby postać następująoej deklaraoji* 


n &zwa monitora* monitor 

tę^gin ... deklaraoje zmiennyoh lokalnych ...; 
prooedure nazwa prooedury ••• t 

begln ... oiało prooedury ••• and; 

...deklaraoje innyoh prooedur...; 

...nadanie wartośoi początkowyoh zmiennym lokalnym ... 
end; 

^ w °łani Q którejś z prooedur danego monitora odbywałoby się za 

P0lQrj f ,, 

'" następującego zdania* 

^zwa monitora .nazwa procedury (••• parametry aktualne) 


^ Sienne lokalne w monitorze mają wiele wspólnego ze zmienny- 
. ^PU own, gdyż również "żyją" dłużej niż trwa wykonanie, 
/j^iuższej nawet, prooedury tego monitora. "Żyją" tak długo, 
w ^^tgo jest ważna deklaraoja oałego monitora. Deklaraoję tę 
jednak roz umi eć inaozej niż deklaraoję prooedury ozy 
;^ji. Zadeklarowanie monitora powinno bowiem być w y k o- 
11 i e m jego programu, tzn. 


, ^klarowaniem zmiennyoh lokalny oh 
1 .^klarowaniem prooedur 

"^^niem wartośoi poozątkowyoh zmiennym lokalnym. 


i:, ‘' zatem próbę rozwiązania problemu zmiennyoh, które mają 
fc 1 kalne, jeśli ohodzi o dostęp do nioh, a jednooześnie glo- 
, jeśli ohodzi o "ozas ioh żyoia". Nawiasem mówiąo, z 

Szykowego punktu widzenia trudno byłoby uzasadnić, dla- 
Prooedury wohodząoe w skład monitora są dostępne także 
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posa nim samym, natomiast zmienne w nim zadeklarowane są nie - 
dostępne. Innymi słowy dlaozego poprawne jest wywołanie! 

nazwa monitora*nazwa prooeduiy parametry aktualne. 

natomiast będzie błędem użyoie zmiennej! 
nazwa monitora.nazwa zmiennej 


?. PROCESY RÓWNOLEGLE 

W żadnym z trzeob wymienionyoh języków programowania - 
i ALGOL, PASCAL i FEAHL!- nie mamy możnośoi wyrażenia tego, ż* 
wykonywanie pewny oh zdań programu powinno być równoległe. Ni« 
możemy wyrazić nawet tego, że nie musi ono następować w taki® 
porządku, w jakim owe zdania są napisane. Jednakże w litera tu 
rze można znaleźć wiele propozyoji uzupełnienia tych językć* 
o speojalny nawias, wskazujący możliwoóó równoległego wykonJ" 
wania zdań lub wyrażeń nim objętyoh. 

A więo np. Dijkstra [2] zaproponowali 

parbegln 8^; S 2 ;...;B Q parend , 

Brinoh-Hansen [i] podał propozyoję różniąoą się od powyż' 
szej tylko formalnie 

oobegin S 1< S 2 ł»..t8 n ooend . 

Istotne różnioe pomiędzy obiema propozyojami dotyozą zaP 1 ' 
su ewentualnej synohronizaoji wykonywania zdań S-,, S 2 ,... s n* 
Dijkstra wprowadził w tym oelu nowy typ zmiennyoh - sema fgg 
i dwie operaoje działająoe na taki oh zmiennyoh - P i V. Na* 0 
miast Brinoh-Hansen zaproponował nową postać zdania! 

region t do ... ozęść programu operująoa na zmiennej 

v ... end 

określająoa dla danego procesu jego przedział krytyozny ze 
względu na zmienną v. 

Nie będziemy tutaj szerzej omawiać obu propozyoji, gdyż 
stały one szozegółowo wyjaśnione w oytowanyoh praoaoh. Zvr' L 
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ty natomiast uwagę na niektóre problem? wynikająoe z rozważań 
0 znaozeniu zdania postaci* 

oobegin S^j Sg}...} S n ooend 

W szczególnym przypadku może to być np« zdanie* 
oobegln S(a)ł S(b) ooend , 

S jest uprzednio zadeklarowaną procedurą z jednym para- 
^trem formalnym. Program stanowiący ciało tej procedury może 
kyó wykonywany jednocześnie przez dwa prooesory, przy ozym oba 
Skonania (prooesy) odnoszą się do różnyoh parametrów aktuał- 
ty°h. Zatem jeden parametr formalny ma być związany na raz z 
^ w °ma aktualnymi. 

Najprostszym rozwiązaniem tego problemu jest reguła kopiowa¬ 
ne ciała procedury w miejsoe jej wywołania wraz z zamianą pa¬ 
rametrów formalnych na aktualne. Zauważmy, że deklaracje zmien- 
jakie mogą wystąpić w oiele tej procedury muszą być rów- 
nl «ż kopiowane tak, by zadeklarowane zostały dwa różne komplety 
Siennych, mimo iż z tymi samymi nazwami. 

Rozważny teraz inne rozwiązanie, w którym ciało procedury 
będzie kopiowane w miejsce jej wywołania, natomiast program 
^arty w jej ciele będzie rzeczywiście wykonywany prze? dwa 
^OceBory na raz. Jednakże w samym programie nie może być in- 
^ 0ri maoji o dwóch na raz parametrach, ani też o dwóoh na raz 
^°npletaoh zmiennych w nim zadeklarowanych. Jeżeli nawet mogło¬ 
by tak być, to powstałby problem, jak dany procesor miałby być 
2w lązany z jednym parametrem i jednym kompletem zmiennyoh przez 
° a ty czas wykonywania tego programu. Widać stąd, że każdy pro- 
CQ sor mua i zawierać w sobie niedostępną dla innych informację 
° tym, z którym parametrem aktualnym i którym kompletem zmien- 
ty°b ma do czynienia wykonując program takiej procedury. 

Zatem przyjmując to drugie rozwiązanie dochodzimy do ozegoś, 
°° poziomie języka maszynowego określa się ozęsto jako re- 
J<j 8tr bazowy procesora. Zauważmy, że taki rejestr jest konieoz- 
ty nawet wówczas, gdy próoesy są tylko ąuasirównoległe, reali- 
2 °Wano przez jeden procesor. Mają one bowiem być między sobą 
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synohi*onizowane, a więo Jeden watrzy mywany a drugi wznawiany• 
oo oznaoza, że również i w tym przypadku będą "iabnioć obok 
aiabie" oba parametry aktualne i oba komplety zmiennych. 

W przypadku wielu prooeaorów, Jak Już wykazaliśmy, rejes*' 1 ' 
ów utuai być ozęśoią składową każdego z nioh, natomiast w prS/' 
padku prooesów ąuaBirównoległyob wyBtarozy, by był to pointa* 
wskazująoy, na któiym parametrze i którym kompleoie zmienny 011 
prooeaor ma działać. Wartość tego pointera ulega odpowiednik 
zmianie, gdy następuje przełąozenie prooesora z Jednego pro° 9 
bu nu drugi. 

Mówiąo o prooeBaoh wykonywany oh równolegle lub guanlrówn 0 ' 
legie powinniśmy zdawać b >bie sprawę, że Już z góry zakładać 
istnienie pewnego systemu operaoyjnego, którego zadaniem J 0flt 
dokonywać przydziału procesorów poszczególnym prooesom (ozy lł 
przydziału proaesorów do wykonywania zdań 8, ]t S-,,,.., • 

A w przypadku, gdy prooesorów będzie mniej niż prooesów, ^ 
ów system operaoyjny będzie procesory "rozmnażać" (ożyli 
nywać tzw, podziału ozaau). Zatem przyjęoie powyższyoh prop o!!y 
oji zapisu zdań wspólbieżnyoh oprawiłoby, że byłby to języ* 
nieoo zbyt wysokiego poziomu, przynajmniej Jeśli ohodzi o P 1 " 
sanie programów przydziału i "rozmnażania" procesorów. 


4. PRZYDZIAŁ PROCESORA 

Oazywiśnie przydział prooesora (ożyli zainicjowanie lub 
wznowienie proaeeu), tj. skierowanie go do wykonywania Jaki 0 " 
goś Zdania programu, nie ^bywa się poprsez zdanie go tfi. M * 
wiąo o przydziale procesora mamy na myśli to, że procesor 
H doohodzi" do tego zdania w inny sposób niż to wynika z dyna" 
raioanego porządku wykonywania zdań sktedająaycb się na dany 
program* 

Rozważny zdanie z poprzedniego paragrafu! 
oobegin Agi*’** ®n °°-— 

i załóżmy, że zanim doszło <*9 wykonywania tego zdania, rsn* ^ 
zowąny był ty lito Jeden proces, a więo potrzebny był tylko 
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‘ Prooesor. W procesie tym być, może doszło do deklaraoji ja- 
zmiennej. Zatem owa zmienna ma być wspólna dla równole- 
^ Prooesów, stanowiąoyoh wykonanie zdań S^, Sn,...! S n< 
**^02a to, że ma ona być dostępna nie tylko dla procesora, 

' ,ry ją zadeklarował, ale również dla tych prooesorów, które 
° 8 taną przydzielone do wykonywania zdań S^, S 2 ,..., S n . Wobec 
Jf -° Przydział prooesora powinien być m.in. ''powiadomieniem" 

0 istnieniu tej zmiennej. Innymi słowy, ma on "wiedzieć" 
,' 2y0 tko to samo, co "wie" ów pierwszy prooesor. Zatem przy- 
Procesora miałby być równoznaczny z jego "utożsamieniem 
r z tym prooesorem, który do tej pory realizował program. 


. J ®ćnakże oałkowite "utożsamienie się" oznaozałoby dalej rea- 
2 °»anie dokładnie tego samego prooesu (wykonywanie tego sa- 
. 80 Programu). A przeoież ohodzi o to, by różne prooesory by- 
„ Wydzielone do różnych prooesów. Z tego wniosek, że owo 
Ut °ŻBamienie się" nie może być oałkowite. 


POł, 


^ ^Owataje teraz problem określenia, jak to utożsamienie się 
2Ul| iieć i których zmiennyoh oraz parametrów ma dotyczyć. Rzeoz 
być jednak rozważona w powiązaniu z problemem, jak ro- 
^ć odbieranie prooesora procesom (np. wtedy, gdy prooes się 
°ćc 2 ył) oraz jaki program wykonuje prooesor, kiedy przestał 
^alizować jeden prooes a jeszoze nie zaczął innego. Jeżeli 
°fcyany, że jest to program oczekiwania na informacje od inne- 
PRooesora (np. informacje o tym, że jakiś prooes może być 
J lftlo dowany lub wznowiony), to oały problem musimy znowu roz- 
j^Sywać od początku. Przekazywanie informacji oznacza bowiem 
.^Pienie wspólnyoh zmiennyoh, a przeoież problem wyniknął z 


» dak procesor ma się "dowiedzieć" o istnieniu wspólnej 
Wej. 


M Zważmy, że na niższym poziomie języków programowania, 

operuje się pojęciami pamięć maszyny i adresy poszoze- 
J%oh słów, ozy bloków, problem nie istnieje. Cała pamięć 
b yć traktowana jako wspólna dla wszystkich prooesorów. 
zatem deklaracje będą traktowane statycznie, tzn. będą 
’ Otynie informacje- dla kompilatora, który już w fazie trans 
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lao ji rozplanuje położenie wszystkioh zmlennyoh (1 programów) • 
to nie będzie problemów operaoji na pamięoi związanyoh z deki*' 
rowaniem zmlennyoh, a więo i problemu "utożsamienia się" jedz* 
go prooesora z drugim* Przydzielenie prooesora do prooesu po¬ 
winno wówozas niewiele różnió się od £0 to. Byłoby to Jednak 
z pogwałoenlem kardynalnej zasady mówiąoej, że za pomooą g£ *S 
nie powinno się wohodzió do wnętrza bloku, prooedury ozy fuh^- 
oji (nie mówiąo Już o tym, że zdaniem wielu autorów, stosować* 
go to powinno być w ogóle zabronione) • Poza tym, Jak wspomni®' 
liśmy w paragrafie 2, deklaraoje traktowane statyoznie spra^ 9 
ją pewne kłopoty, a jeśli dotyozą każdego rodzaju zmlennyohf 
praktyoznle uniemożliwiają rekursję* 

Problem przydziału i odbierania prooesora ma jeszoze jede 11 ' 
być może nawet głębssy aspekt. Otóż z punktu widzenia systemu 
operaoyjnego problem ten to problem sterowania procesami, ^ 
znaozy wykonania programów użytkowników. Natomiast z punktu 
widzenia użytkowników system operaoyjny świadozy usługi, to 
znaczy ioh programy niejako sterują systemem operacyjnym. 
tego też przyjęło się mówić o wywoływaniu prooedur systemu op# ^ 
raoyjnego. A przeoiwż, z pierwszego punktu widzenia, można 
nie dobrze mówić o wywoływaniu programów użytkowników. Wydają 
się, że każdy, kto miał do czynienia z programowaniem systc» 
operaoyjnyoh, uświadamiał sobie ten dylemat. Ponieważ jednak 
pisał programy w języku mas^nowym lub do niego zbliżonym, P 
sługiwał się pojęoiami takimi jak adresy i podprogramy. A _ 
pozwalało na odwraoanie wspomnianej hierarohii w miarę potr*® 
by lub też na sprowadzenie wszystkiego do jednego poziomu r° 
mowania. Natomiast w stosowaryoh dotyohozas językaoh progra® 1 ^ 
nia wyższego poziomu trzeba wyraźnie określić hierarohię ste 1 ^ 
waniał nawet jeżeli prooedura a będzie wywoływać procedur? 
a ta z kolei prooedurę a, nie oznaoza to odwróoenia hierar¬ 
ohii, tylko rekursję* 
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** ZAKOŃCZENIE 


®rak w literaturze pozycji, w których można byłoby znaleźć 
^zykład zaprogramowania oałego systemu operaoyjnego w jakimś 
^dnym języku wyższego poziomu, zdaje się potwierdzać raniema- 
n * e autora o nieprzydatności takich języków w ich obeonej po- 
s ^aoi ( 3 0 -tego celu. 

Nie oznaoza to jednak, by nie podejmowano prób struktural- 
tle 8o programowania systemów operaoyjnych. Sposób postępowania 
1 takim programowaniu bardzo jasno przedstawił Dijkstra [5] 
Praoy tylokrotnie już na tym sympozjum oytowanej. W wielkim 
6k *>oie metodę tę można przedstawić jako konstruowanie kolej- 
ooraz wyższych poziomów oprogramowania wychodząc od ję- 
J 1 Daszyny. Innymi słowy jest to definiowanie kolejnych ję- 
programowania danej maszyny korzystając za każdym razem 
^Szyka poziomu niższego. Zatem system operaoyjny powstaje ja- 
Pewien hierarchiczny zbiór programów, napisanyoh jednak w 
językach, odpowiednio do poziomu, na którym program 
**34uje się w oałej hierarchii# 


tu 


S^ątura 
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Jacek OLSZEWSKI 


nPOEJIEMU CTPyKTyPHOrO nPOI?AMMHPOBAHHfl OQEPAUHOHHUX CHCTEM 
PeąBMe 


CTpyKTypHHM nporpaMMHpoBSLHaeu npBHHTO onpeneraTL T&Koit 
MeTOn nporpaMMupoBainiH, KOTopufl noasoraeT nojiyaaTL nporpau- 
m b Ban© aeTKofi soKyMeHTauaa. Hotkoctl noKyMeHTauaa hoctb- 
raeTca nyT«M xopomero onpeneaeHHH CTpyKTypu nporpaMMU. Ha 
KaaaoM ypoBH© btoK CTpyKTypu Hac HHTepecyeT tojibko to, hto 
naHHaa nporpaMMa (npouenypa, nonnporpaMMa) BunoraaeT, a h© 
KEKKM odpa30M. OdCyKH©HH© Toro, KBKHM OdpaSOM, HBJIH6T0H 110- 
P©xohom k cnenyiomeMy ypoBHD CTpyKTypu, Ha kotopom chobb no- 
hbahdtch nporpaMMU (npoueflypu, nojuiporpaMMU). Otbst Ha boh- 
pOCt HTO HMH BUnOJIHHeTCH, 0 HH 0 Bp©M©HH 0 HBJUłeTCH 0TB8T0M Ha 
Bonpoc: krkhm oópa 30 M BtmoraaeTca nporpaMMa npejmnymero 
ypoBHH. BjieMeHTapHue onepamw naHHOft Mama hu ara asuKa npo- 
rpaMMapoBaran floraHU hbjihtlch noojienHBM ypoBHCM CTpyKTypu. 

3HaHHT©raHyB noMOiuB b TaKOM cocTaBJiemoi nporpaMM 0Ka3U- 
BamT npouenypHU© h3ukh nporpaMMHpoBaima, Hanp.A lgol, Pascal 
a b nocjierae© bp©mh odraK BHTepec BU3UBa©T h3UK pearl , 
npejuiaraeMufi b bhh© H3HKa CTpyKTypHoro nporpaMMHpoBaHna. 

C upyroli otopohu bsbsctho, rto ho chx nop onepauHOHHue 
0B0T6MU, a no Kpataeft M©pe nx dasoBue «acTB, nporpaMMapy- 
iotch Ha MamHHH ŁUC H 3 UKax ara Ha H3UK© acceMdJiepa, de3 hc- 
nojiŁ30BaHHH CTpyKTypHoro M©Tona.]loKyMeHTamiH chctsmu Bcer- 
Ha HBraeTcn cepte 3 H 0 K npodaeMoft b HysnaeTca, KpoMe tokctob 
caMBX nporpaMM, ©me b hx onHcaHHB Ha HeiJopMaraHOM h3Uk©. 

B HacToameft pa 3 padoTKe aBTop nuTaeTca otBeTBTŁ Ha Bonpoc, 
noaewiy nponenypHue fl3UKH b mc HacToameft $opMe, a naxe b 
$opM© cneimaJiLHO nonodpaHHOtt jyia npencTaBJieHua aacTeft one- 
paimoHHoK CHCT6MU, HenparonHU raa mc nporpaMMupoBaHna. 
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*°blbms of 


STRUCTURED PROGRAMMING OF OPERATING SYSTEMS 



ftmo^ rUc * ure< * Programming is meant as a programming method that renders, 
n 8 others, a program text to be its own, readable documentation. It 
possible only when the program structure is stated clearly. At 
^ eve l of the structure we are interested only in what a given pro- 
^P roc ®dure or subroutine) does, not in how it does. A "how" con- 
Pro Qra ** 0n means nex ^ level of the struć turę t where again 

to ? faias (procedures or subroutines) are to be dealt with. The answer 

qU9flt ^ on wha t they do is the answer to the ąuestion how they do 
gra Q * 0rmer lovel, Elementary operations of a given machinę or ii 
language become the last level of the structure. 

g ta £ r ° ce dural programming languages - e.g. ALGOL, PASCAL - provide a pro- 
ą ^ ® r with a substantial help in such method of programming. Recently, 
•tr ® ua S e PEARL has been discussed as a tool specially developed for 
thiH Q * ure< * Programming. On the other hand operating systems or at least 
basie parta are programmed in machinę languages or assemblers, in 
tln Wa ^ bhat is far from the structured one. Operating system documenta- 
l 0 * * a always a big problem which is being solved in the form of dę¬ 
biona written,unfortunately, in unformalized languages. 


pro- 


^ content of the present paper is an attempt to answer the ąuestion 
Pro ^cedurel languages in their today forms, or even in forms especially 
£ 0r describing parta of operating system,are not used for their 

°fcramming. 


0 ) 

& 
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*i/ 4 } łUc «J* Egzekutora mają na celu rozszerze- 
Pr Qw w9 E° własności funkcjonalnych i mogą być 
&zone w dwóch podstawowych kierunkachs 

Ur ^°**nie oprogramowania niestandardowych 
*^ z ®ń zewnętrznych, 

Wadzenie ułatwień programowych, umożli- 
n^^^cych konstruowanie fragmentów 


Kik. 


% «oi 


systemu 

^^-jjnego, działających na poziomie pro- 


^ u użytkowego* 

* Praw w P r °wadzone do Egzekutora 

tycznie opracowanych systemach. 


wykorzystano 


Spis treści 

1 , 

5 

J ( Ta BL1ce programu egzekutor 
3 ^dyfikacje programu egzekutor 

3 ^ pr Qgramowanie niestandardowych urządzeń zewnętrznych 

^Prowadzanie ułatwień programowych umożliwiających konstruowanie 
K % * ra gmentów systemu operacyjnego na poziomie programu użytkowego 
^lOSKI 








174 


Janusz PIELA, Wojciech SKURZAK 


1. WSTĘP 

Rozwijająoe się różne dziedziny zastosowań maszyn cyfrowy^ 
stawiają ooraz większe wymagania zarówno w zakresie sprzętu 
jak i oprogramowania. Często zaohodzi konieczność budowy wąs^ 0 
wyspecjalizowanyoh systemów, których elementami powinny być 
speoyfiozne dla nich urządzenia. 

Firmowe oprogramowanie dostarczane przez producentów masz? 11 
oyfrowyoh ma najozęściej charakter uniwersalny i nie spełnia 
zadań stawiany oh przed systemami wyspecjalizowanymi. Powstaj 0 
więo problem budowy systemów operaoyjnyoh dla speojalnyoh ^ 
stosowań maszyn oyfrowyoh. 


Opraoowanie od podstaw takioh systemów jest bardzo ozas° 
chłonne oraz wymaga dużego nakładu sił i środków. Cechą cha 
rakterystyozną współczesnego oprogramowania powinna być zno*** 




wość jego modyfikaoji w celu dostosowania do nowych zastoso 
Pozwala to na wprowadzenie nowyoh elementów oprogramowania P 
zachowaniu wszystkich możliwości funkojonalnyoh oprogramować 
firmowego. 

Ceohę taką posiada oprogramowanie maszyn cyfrowych systefl u 
ODRA 1JOO. Producent oprogramowania zapewnia, że istnieje 
liwośó modyfikaoji programu nadzorczo-sterująoego, jakim i 00 
program Egzekutor, jak również możliwość rozbudowy bibliotek 
podprogramów obsługiwanych przez kompilatory poszczególnych 
języków programowania. Modyfikacji programu Egzekutor można 
dokonywać przy codziennej eksploataoji systemu. Jednak do w ^ 
nania nawet najprostszych modyfikacji Egzekutora konieczna 0 
znajomość zasad jego pracy i budowy. 


Analizę możliwości modyfikacji Egzekutora przeprowadzono 
w związku z koniecznością dołączenia oprogramowania niestafl 
dardowyoh urządzeń zewnętrznych, np. grafoskopu, urządzeń ' 
misji danych. Głębsza analiza wykazała, że przez modyfi** 
można również zmienić własności funkcjonalne Egzekutora, zd ° 
wująo całe dotychczasowe oprogramowanie, tzn. kompilatory 1 
standardowe programy użytkowe. 

/ 
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^owe funkcje dołąozone do standardowego Egzekutora wykorzys- 
są najczęściej za pośrednictwem nowyoh ekstrakodów. 
“^trakody te można bezpośrednio stosować w językaoh symbolios- 
np. NSBL, PLAN. Można ioh również używać w programach napi- 
w językaoh wysokiego poziomu (np. ALGOL, COBOL, FORTRAN) 
wstawki w języku PLAN. 


2 . 


^BLICE programu egzekutor 


E 82 ekutor w czasie praoy maszyny znajduje się stale w ohro- 


kut 


‘,-m obszarze pamięoi operacyjnej. Głównymi funkojami Egze- 


°ra 


sąi 


Ozorowanie wykonywania programów, 

,* Ozorowanie praoy urządzeń zewnętrznych, 

. Zlizać ja ekstrakodów, 

5 ‘ ^onywanie akoji specjalnyoh (np. ładowanie programu), 
' ^munikaoja z operatorem i wykonywanie jego poleoeń. 


W Programie Egzekutor przechowywane są informacje dotyoząoe 
^yatkioh programów znajdująoyoh się w pamięoi operacyjnej ma- 
Informaoje o programie można podzielić na dwie grupy: 

' lnf ormaoje identyfikujące program i określająoe przydzielo- 
n ° Programowi urządzenia zewnętrzne oraz wielkość obszaru 

P *»ięoi, 

* ltlf Onnaoje określająoe aktualny stan programu. 

^ formacje te przeohowywane są w tablioaoh opisu programów 
w ° bs zarze Egzekutora. Opróoz opisu programów znajdująoyoh się 
„^ięoi operacyjnej maszyny, konieozny jest również opis 
^ózeń zewnętrzny oh dołąozonyoh do maszyny. Informaoje słu- 
4o opisu urządzeń zewnętrznych możemy podzielić na dwie 

Ny : 

określające własności danego urządzenia zewnętrznego 
^ a Posoby odwołania się do niego, 
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• zmienne, określające stan urządzenia zewnętrznego w każdej 
ohwili ozasu i przynależność do określonego programu. 

Informacje te znajdują się w kilku różnych tablioaoh opi sU 
urządzeń w obszarze Egzekutora. 

Tablice opisu programu i opisu urządzeń zewnętrznyoh *7^° 
rzystywane są przez podprogramy Egzekutora. W oelu skróoenJ- a 
ozasu dostępu do żądanych informaoji są one rozmieszczone 
kilku różnyoh tablioaoh powiązanyoh logicznie ze sobą. 


3. MODYFIKACJE PROGRAMU EGZEKUTOR 

Modyfikacje programu Egzekutor mają na celu rozszerzeni® 
jego własnośoi funkcjonalnych. Mogą one dotyczyć: 

• oprogramowania dołączonyoh do maszyny niestandardowych 
dzeń zewnętrznych, 

• wprowadzania ułatwień programowyoh umożliwiających kons^ 
wanie fragmentów systemu operacyjnego na poziomie progi*® 
użytkowych. 

Uzupełnienia programu Egzekutor mogą być wykonane: 


• jako niezależne pakiety wymagające jedynie określenia P 
tów wejśoia i wyjśoia w dotychczasowym Egzekutorze, 


u**' 


• jako niezależne pakiety wykorzystujące dotychczasowe wł ft 
wośoi i podprogramy Egzekutora. 


koi' 


3.1. Oprogramowanie niestandardowych urządzeń zewnętrzny® 11 

ętt*' 

Technicznemu dołączeniu niestandardowych urządzeń zew* 1 * 
nych do maszyny systemu ODRA 1300 musi towarzyszyć oprogń 9 ®^,, 
wanie ich na poziomie Egzekutora. Ważne jest aby sposób - j9 ^ 
pracy z tymi urządzeniami nie odbiegał od sposobu współp^ 
z urządzeniami standardowymi. Polega to m.in. na stosowa**■ 
typowych ekstrakodów. W niektórych przypadkach celowe był 0 
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stosowanie dodatkowyoh ekstrakodów. W ogólnym przypadku jednak 
d la zapewnienia możliwośoi wykorzystywania niestandardowych 
^rządzeń w programaoh pisany oh za pomocą różny oh języków 
Programowania należy zaohowaó istniejąoe standardy. Opraoowa- 
n lo pakietu oprogramowania nowego urządzenia zewnętrznego nie 
3«st zhyt trudne. Pakiet taki składa się z dwóoh podstawowyoh 
Cementów: 

• 0 Pisu urządzenia, 

• Podprogramów współpraoy z urządzeniem. 

Opis urządzenia w pakieoie stanowią informaoje będąoe po¬ 
dojami poszozególnyoh tablio opisu urządzeń zewnętrznyoh w 
®6zekutorze. Przy opraoowaniu oprogramowania nowego urządze¬ 
nia zewnętrznego należy wląozyć do istniejąoyoh tablio Egzeku¬ 
tora pozyoje oharakteiyzująoe dołąozane urządzenie. Informaoje 
'^ieszozone w tablioaoh opisu urządzenia wykorzystywane są 
Pr*ez podprograny gospodarki urządzeniami zewnętrznymi, podpro¬ 
gramy komunikaoji z operatorem, jak również podprogramy iniojo- 
*ania i końozenia transmisji. Oprogramowanie każdego urządzenia 
Powinno uwzględnić jego speoyfiozne oeohy. Z tego powodu nie 
można ściśle określić standardu oprogramowania wszystkich urzą- 
^*80 zewnętrznyoh. 

W przypadku opraoowania nowyoh ekstrakodów współpraoy z do¬ 
wożonym urządzeniem można wykorzystać kody ekstrakodów niewy¬ 
korzystane w konkretnej wersji Egzekutora. Oprogramowanie dołą- 
° a onego urządzenia stanowi wówozap niezależny podprogram. 
tu nktami wspólnymi z Egzekutorem są tylkot 

% Punkt wejśoia do podprogramu obsługi urządzenia z podprogra¬ 
mu Egzekutora dekodująoego poszczególne ekstrakody, 

% Punkt wyjśoia z dołączonego podprogramu do podprogramu Egze¬ 
kutora realizująoego powrót do programu użytkowego. 

Praktycznie przeprowadzono dwie modyfikaoje. Pierwsza z nioh 
U możli w ia wykorzystanie systemowej konsoli operatora do współ- 
z programem użytkowym. Celem tej modyfikacji było stwo- 
możliwośoi prowadzenia eksperymentów w zakresie organi- 
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zaoji praoy konwersaoyjnej przy wykorzystaniu dostępnego z 0 ' 
stawu maszyny. Zrealizowany został dodatkowy ekstrakod, który 
pozwala na wprowadzenie i wyprowadzenie informacji ze wskaza® 0 ' 
go obszaru pamięci operacyjnej programu użytkowego. Druga 
fikaoja umożliwiła dołączenie do maszyny cyfrowej ODRA 1J04 
urządzenia transmisji danych UTD-211. W obecnej chwili opra<J°^ 
wane jest oprogramowanie umożliwiająoe współpraoę maszyny oy" 
frowej ODRA 1504 poprzez urządzenie UTD-211 z minikomputerom 
M0MIK-8b. 


■ ,-U' 

5.2. Wprowadzanie ułatwień programowyoh umożliwiająoyoh kona 1 ' 
owanie fragmentów systemu operaoyjnego na poziomie proS r 
użytkowego 

W trądy oyjnej praoy z maszyną cyfrową ODRA 1504 wykonywa®* 0 
programów nadzorował operator maszyny, nadając odpowiednie ^ 0I# 
nikaty do Egzekutora oraz śledząo wydruki na konsoli. Tak z ° 
nizowana praoa znaoznie wydłuża prooes przetwarzania oraz 
od operatora znaoznego wysiłku umysłowego. Ponieważ w maszy 0 * 0 ^ 
ODRA 1504 można przetwarzać równooześnie oztery programy, 
oje operatora mógłby przejąć jeden program i sterować prao4 
zostałyoh trze oh. Takie sterowanie pracą programów wymaga. * 
by wybrany program nazywany dalej sterująoym mógł nadawać * 
nikaty operatorskie do pozostałyoh trzeoh programów nazywać 
dalej sterowanymi oraz,żeby informaoje o zdarzeniach jakie ^ 
dą w programaoh sterowanyoh były przekazywane do tego jednej 
wybranego programu. Aby to zapewnić opraoowano nowe ekstrak 0 
o następujący oh znaozeniaoht 

c wyróżnij program - ekstrakod ten powoduje zaznaozenie w 
blioaoh opisu programu w Egzekutorze, że program jest wyr " 
niony, 00 oznacza, że będą do niego przekazywane inforro* 0 ^^ 
o rozpoznanyoh przez Egzekutor zdarzeniach w sterowanyoh V 
gramach, 


o wykonaj komunikat z pola programu - ekstrakod ten powoduj 0 
wykonanie przez Egzekutor komunikatu operatorskiego, który 
podany jest w obszarze programu sterująoego. Dopuszozaln 0 
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* #2 mkie komunikaty operatorskie; komunikaty te mogą doljy- 
ładowania programów, inicjowania ioh praoy, zawiesza- 
itp. 


program sterująoy — eketrakod ten pozwala na zawiesza** 
® le Programu sterująoego i przejśoie do wykonania innyoh pro- 
Krapów. Program sterująoy oozostaje zawieszony aż do wystą- 
w którymś z programów sterowanych jednego z określo- 

zdarzeh, 

1 ' 58u Ó wyróżnienie programu - ekstrakod ten pozwala na usunię- 
01,5 znaoznlka z tabel Egzekutora oznaozająoego, że program 
l8 ®t programem sterująoym praoą innyoh programów. Po wykona- 
^ tego.ekstrakodu nadzór nad wszystkimi programami przejmu- 
°Perator. 


Zn Pomooą powyższyoh ekstrakodów opracowano już dwa progra- 
, 8t erująoe. Pierwszym z nioh jept program sterująoy praoą sys- 
J*’ 1 Przetwarzania danyoh. Program ten zajmuje zaledwie około 
J* 8 ł6w pamięci operacyjnej. Drugim jest System Automatycznego 
^hamiania Programów. Jest on przystosowany do kompilatorów 
PLAN. 


^Pracowano ekstrakody umożliwiają pisanie programów sterują- 
poziomie programu użytkowego w dowolnym dostępnym w 
ODRA 1JOO języku programowania np. PLAN, ALGOL, 

, itp. pozwala to na praktyozne sprawdzenie konoepoji 

^kim ozasie. 


’ ^lOSKi 

, J^gą modyfikaoji można znacznie rozszerzyć możliwośoi pro- 
C U Egzekutor. Nie jest to zbyt trudne, jeżeli znana jest 

i zasady pracy programu Egzekutor. Egzekutor z omówio- 
lianami eksploatowany jest już przez pół roku i nie 

"zakłóoeń w praoy programów, które nie korzystają 

*°*adzonyoh udogodnień# 


[ 
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PACUMPEHKE OyHKLlJlOHAJDbHbDC B03M0IH0CTEH UPOITAMMbl EXECUTIVE 
JUIfl 3BM CDRA-1304 

P9310M6 


MoHHiJjHKauHH nporpaMMH executive HMeei nejiBio pacumpuTB 
$yHKLoiOHajiBHue cBoiicTBa h MoxeT npoBonHTBCu no uByM ochob- 
hhm HanpaBJie huhm : 

1. IIojmJiioneHHfl MaTodecneHeHHH HecTaHnapTHHX BHeuiHHX 

ycTpoMcTB ; 

2. BBefleHHH nporpaMMHŁDC cpencTB, no3BOjiraomnx pa3padoTaTi> 
3JI6M6HTU OnepanHOHHOft CHCT6MU, $yHKIWOHHpyromHe Ha 
ypoBHo npHKjianHofi nporpaMMH. 

M3MeHeHHH, BBeneHHoe b nporpaMMy executive , Hauuui npaKTH" 
necKoe npnM6HeHH8 b pa3paóaTUBaeMux ohct8mbx. 


INCREASE OF FUNCTIONAL FACILITIES OF THE ODRA 1304 EXECUTIVE 


Summary 

The modifications of the Executive are lntroduced to give additi 0 ^ 
functional facilities for ita users. The modifications oan be added 
two following wayaj 

1. adding the software for non-standard peripherals, c \ 

2 * lntroducing the elements of software, enabling one to wrlte cont fv 
programs at user s program level # 

These modifications have been tested practically. 


(c) Instytut Maszyn Matematycznych 
02-078 Warszawa, ul. Krzywickiago 34 
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PnklHii pray kwaraanlu kUllitikl 
Uatk v V° h łMlł«w aanipulaayjnyah jaak lak 
,J' M l tólnaradnaid apaaabćw korayakanla pray 
aafata padobnya datalanlu. V apra- 
luikt P»aa 6 akawla»a idaa alatairawaayah aaat- 
Mw « * w paawalająią aradukawad liiikf proara- 
iil.^PuUoyJnyah da kilku araa ujadaallaid 
ki!”® karayakanla a nlah. Oikniw aoakala 
ig budawy prairtau fldwnaia apalaiająaa- 
ynjJ^akła funkaja praaa vywaływanla aiduldw 
i|!, >lu M«)fok wyapaajaliaawana Badania, pray 
kyPJMira. yłowny i aaduly raallaująaa nagą 
Iw ,! 1 >lM *' a rdiayah jaaykaah prasraaawanla. 
apraaawania aiały alf praktyaaaa da> 
wynikła a praay pray aarwiaia apra- 
aaaayay MM 41 araa v krakała kwa- 
OjyjjH bibliakaki opr«iraaavanU> w ayakaaia 


Ipla kr a'dat 

[' ta »IW|lAfQM 1 ZOH MiaJBOI W IYI9BMZB OMOOBAHOYANZA INO 
' **kIPUUTOJ|¥ v MA8BYNA9H W0B88NYG11 OINIBAUZ 
\ MOtblWOdOI III OBNBBAOtll 8MQ 
Q| *» miOBAWZ HAHlPOŁATOkflW 

’ MAŁHA04Z BZNJB8B9YANYGR MAkiPUMfORllw NA INO IBM 160, 170 
* *&9 ZMM W 8Y8IBH1B 98/160 
ifttairaaja fiiyaana 
g *» Zakigneja legleana 
' 5ą U9NHTB imiY 
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1. MANIPULATOR! I ICH MIEJSCE W SYSTEMIE OPROGRAMOWANIA EMC 

W niniejszym opracowaniu przyjęto założenie, że maszyna <#' 
frowa jest wyposażona w oprogramowanie podstawowe. Rozumiani 
przez to, że istnieją już programy supervisora. programy r 0a ' 
lizaoji metod dostępu (data management) oraz translatory P eW ‘* 
nyoh języków. Nadmienić należy, iż w tych dopiero warunkach 
integracja manipulatorów w pełni daje efekty. 

Programem manipulacyjnym lub manipulatorem (utility) na¬ 
zwiemy taki program, który spełnia powtarzalne pomocnicze 
funkcje związane z eksploatacją pewnego konkretnego system 11 
oprogramowania na konkretnej maszynie cyfrowej. Są to wię° 
programy związane z obsługą bibliotek, konserwacją nośników 
i voluminów, edycją wszelkich tekstów w formach zależnyoh 0,1 
tyoh tekstów np. edycja programów zapisanych w konkretny® 
języku z uwzględnieniem struktury tego języka , programy 
wersji danych pomiędzy nośnikami, programy aktualizaoji teJ£S 
tów itp. 

/ j.i 

Na ppdstawie tej charakterystyki można więo stwierdzić* 
są to w większości programy, w któryoh dużą część czasu P ra ' 
zajmują operacje wejśoia-wyjśoia. 

Ze względu na charakter zastosowań są to programy, z 
rymi ma do czynienia prawie każdy użytkownik danego system^ . 
oprogramowania, tak więo bardzo istotne są wszelkie korzy ^ 
które można uzyskać przez odpowiednie opracowanie tyoh P 10 ® 
mów. 


2. MANIPULATORY W MASZYNACH WCZESNYCH GENERACJI 

W związku z ubogim wyposażeniem EMC 0 i I generacji w ^ 
dzenia wejścia-wyjścia i ich stosunkowo małą wydajnością ^ 
na chyba bez ryzyka stwierdzić, że podstawowym edytorem ™ y 
maszyn był w najlepszym przypadku po prostu dalekopis lub^^ 
sywacz kart. Pozostałe funkcje były raczej tak nikłe, że 1,1 
na je pominąć. Maszyny II i III generacji w dużym stopniu 
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leniły sytuaoję w tej dziedzinie. Dzięki wprowadzeniu sto- 
®' , nkowo szybkloh urządzeń wejśoia—wyjśoia oraz wzrostowi 
**ybkośoi EMC zaozęto Je również stosować do wykonywania funk- 
0,11 Pomooniozyoh. Następnym faktem wpływająoym na rozwój pro- 
8ta ®ów manipulacyjny oh była rosnąoa w ogromnym tempie liozba 
iftf °rmaoji prze chowywary oh na maszynowyoh nośnikaoh. Powodowa- 
ir ‘ ^0 konieczność stosowania speojalnyoh programów umożliwia¬ 
nych wizualną kontrolę zawartośoi nośników i ioh maszynową 

^bualizaoję. 

s 2ozególnie w przypadku programów edyoyjnyoh doprowadziło 
to takiej sytuaoji. że niejednokrotnie każdy typ informa- 
miał "swego" edytora. 

c lekawym przykładem Jest tu system oprogramowania 80141 
Zt9 ellzowany w ijjjj na emC ZAM 41, który zawierał 

* 2 Programy aktualizaoji tekstów (POPR, SMAO), 

* 11 edytorów, w tym 5 obsługujące programy napisane w MSAS 
W 2 ależnośoi od kombinaoji wejśoia-^jśoia, 

* ^ Manipulatory związane z obsługą taśmy bibliotecznej sys- 
b®®u oprogramowania B0141, 

* a Manipulatorów związany oh z tekstami zapisanymi w standar- 
^le SMAD, 

* ^ Manip U i a tory związane z tekstami zapisanymi w standardzie 

* 0 *oł o ^ manipulatorów związanyoh z informaoją zapisaną na 
tft 6maoh magnetyoznyoh (TM) w standardzie IMM (grupa OPOS i 
Ibfte). jest to grupa o tyle nietypowa, że zawiera oprócz 
Pt °gram6w konwersji i sprawdzania danyoh również programy 
8 °rtowania, generaoji wydawniotw oraz metrykowania, powia¬ 
nia i sprawdzania taśm magnetyoznyoh. 

„ ^zyznać tutaj należy, iż różnorodność ta Jest w pewnym 
%ni u również "zasługą" autorów niniejszego opraoowania. 
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Na swe usprawiedliwienie możemy dodać, że jak nam wiadomo* 
owa różnorodność dotyozy nie tylko EMC ZAM 41. Już w trakci* 
praoy na ZAM 41 autorzy podjęli udaną ohyba próbę opraoow® 11 * 9 
"uniwersalnego edytora" (VWfD), który zawiera w sobie kil* 4 
reżimów edyoyjnyoh, a dzięki wykorzystaniu aparatu symboli° r 
nyoh operaoji wejśoia-wyjśoia może spełniać funkoje konwe^ 
sji szozególnie w dziedzinie przekodowywania informaoji 2 •* 
nyoh kodów zewnętrzny oh na inne. Manipulator ten spełnia 009 
tępbjąoe funkoje: 


• edyoja tekstów bez stronioowania, 

• edyoja tekstów ze stronioowaniem, 

i .jfl» 

• wydruk kart perforowanych ze stronioowaniem i numerowa^’ 1 ' 

• wydruk tekstów ze stronioowaniem i opatrywaniem stron w 

główki, . „ 

• wydruk programów w MSAS, PJEG, z oddzieleniem ozołówki 
oraz numerowaniem wierszy programu, 

• proste powielanie taśmy papierowej, 

• powielanie taśmy z redagowaniem taśmy papierowej, 

• wielokrotny wydruk tekstów. 


p $ 0 ' 

Jak jednak wykażemy dalej, z naszego punktu widzenia* * 
gram ten jest nie tyle zintegrowanym manipulatorem edyoyj 
ile próbą integraoji kilku programów edyoyjnyoh w jedną ^ 
zyozną oałość. Z drugiej strony dodać ohyba należy, i i na ^ 
poziomie rozwoju oprogramowania jaki reprezentuje S0141 P 
danie takiego programu jest już dużą wygodą. 


W tym samym S0141 autorzy opraoowali grupę programów . 
niająoyoh różne funkoje a związanyoh ze sobą podmiotem ' 
łalnośoi (teksty zapisane w standardzie SMAD) oraz spos o*> 6 
korzystania. Programy te spełniają funkoje: 

• perforowanie wybranyoh elementów z TM zapisanej w stan 1 4 


dzie SMAD, 

• soalanle i powielenie taśm SMAD, 

• metrykowanie i zakańozenie taśm SMAD, 

• sprawdzanie i produkowanie spisu stron taśmy SMAD, 

• zapisywanie taśm binarnyoh w standardzie SMAD. 
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Keasumująo można stwierdzić, że w przypadku programu edy- 
“yjfiego nastąpiła integraoja fizyozna, a w przypadku powyż¬ 
ej grupy programów - integraoja logiozna. 


ił Nowe możliwości iii generacji emc 

®la programisty przejśoie od II do III generaoji odbyło 
hle w aspekoie sprzętu, leoz jakośoiowo innego oprogramo- 
Manęr tu na myśli przede wszystkim ogromny postęp w 

8t and« 


^tk, 


aryzaoji operaoji wejśoia-wyjśoia na poziomie programu 
owego. 


dwa wspomniane wyżej ozynniki pozwalają, zdaniem auto- 
iepiej zorganizować programy manipulaoyjne. 




Ogi era się tu mianow iole możliwość oddzielenia funkoji 
^aoizaoyjnyo^ związan yoh z obsługą wejśoia-wyjśoia od funk - 
-^gicznyoh zwi ązanyoh ze strukturą przetwarzanyoh danyoh . 

*<*ąo dalej można zbudować ramowy program zajmująoy się je- 
obsługą wejśoia-wyjśoia i zależnie od wysterowania lub 
^°rmaoji zawartej w samym tekśoie przetwarzanym, wywołująoy 
. s,B ej biblioteki programy odpowiednie do konkretnego typu 

Nie wykluoza się tu oozywiście wielostopniowego powią- 
^ takich programów. Rozwiązanie takie jest możliwe dopie- 
^ w systemach oprogramowania, w któryoh każdy program z natu- 
^eozy jest jednooześnie przystosowany dzięki aparatowi 
^teinu operacyjnego do praoy jako podprogram innego programu, 
^ Przekazał mu sterowanie* 


* integracji manipulatorów 

„ J sk wynika z powyższego funkcje wspólne na przykład dla 
„ ^ 8 tkl 0h edytorów można przenieść do programu ramowego, a 
t , ^Kramach do przetwarzania różny oh typów tekstów zostawić 
^ 1(0 funkoje logicznie związane ze strukturą tekstu. Uzysku- 
w ten sposób następujące udogodnienia: 
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• modulamość systemu manipulatorów na poziomie programów* 

a. mając program ramowy można uzyskać dużą oszoaędność po d ' 
czas realizaoji grupy programów pozbawionyoh powtarzał' 
nych funkoji organizacyjnych, 

b, duże oszozędności w liozbie rozkazów, 

o. ujednolicenie sterowania i oo za bym idzie ułatwienia 
obsługi, 


e możliwość napisania programu ramowego i programów realia 0 ' 
cyjnyoh w różnyoh językach np. ramowy w języku ASSEMBLEB 
a realizaoyjny w COBOL-u, 


• dużo większą łatwość dołączania i uruohamiania programu ^ 
alizaoji współpracującego z uruohomionym i sprawdzonym P* 0 * 
gramem ramowym, 


• możliwość wykorzystania programów realizacji przez progi 10 ' 
my ramowe spełniająoa różne funkoje, 

• duża mobilność systemu manipulatorów uzyskana pi’zez 
leżnienie programów realizacyjnych od operaoji wejśo 
oia w danym systemie oprogramowania. Zmianie musi u]eo ^ 
ko program ramowy. 


uni 0 * r 


Głównym więo oelem będzie tutaj otrzymanie maksymalnej 
elastyoznośoi funkcjonalnej grupy programów, uproszczeni 0 
sługi oraz minimalizaoja liczby rozkazów maszynowych zufc?" 
ty oh na grupę osynnośoi (np* na czynności edycyjne). 


Warunkiem takiej integraoji będzie więo przede wszystki® 
możliwość wywołania każdego programu przez inny program t J . 
jego podprogram oraz ustalenie jednolitej ale możliwie un ł 
salnej i elastycznej metody przekazywania sterowania i ln . 
maoji do opracowania pomiędzy programem ramowym i program 3 ' ^ 
realizaoji. Następnym warunkiem fizycznej integracji jest 
kie udoskonalenie oprogramowania podstawowego, że cała k° n 
wersja informacji zależnej od typu urządzenia wejśoia-wy^ ^ 
i użytego nośnika lub kodu zewnętrznego na kod wewnętrzny 

szyny odbywa się na poziomie metod dostępu* 
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Podstawowym natomiast warunkiem lntegraoji logicznej jest 
bacowanie dość szozegółowej konoepoji oalośoi grupy manipu¬ 
latorów wchodzących w skład danego systemu oprogramowania 
P f2 *d przystąpieniem do ioh realizacji, a nie odwrotnie, jak 
tlJ często ma miejsce w praktyce. 


5 * s TAN REALIZACJI ZINTEGROWANYCH MANIPULATORÓW NA EMC IBM 
360, 370 w ZDO IMM (W SYSTEMIE 0S/J60) 

~h tegraoja fizyczna 

baonie w ZDO IMM realizowane są dwa programy ramowe oraz 
programów realizaojii 

1 , 

P ro gramy ramowe 

• Program edycyjny 

• Program aktualizaoji tekstów 

^^gramy realizacji 
% e dycja prosta 

• e dyoja ze stronicowaniem 

• e <tycja na dwa wyjścia (np* drukarka i perforator kart) 

% Obieranie określonyoh oiągów dokumentów ze strumienia 

jśoiowego i przekazywanie na wyjście 
% zkontekstowa zamiana tekstów 

% Q 3yoja programów napisanych w języku ASSEMBLER 560 
% 9( ^ycja opisów oprogramowania zmagazynowanego w formie 
źródłowej na maszynowych nośnikach informacji. 

programu ramowego o nazwie VWYD należy pełna 
zbiorów wejśoia-wyjśoia i przekazywanie sterowania 
^Sternom realizaoyjnym przed wyprowadzeniem każdego z doku- 
na gińcie oraz w momenoie końca danyoh i wykrycia 

^6w, 

v ?Uj ń£oja obsługi zbiorów wejśoia-wyjśoia polega między inny- 
^ 114 Prze ozytaniu infomaoji zawartyoh w zbiorach opisanych 
kol »dnyoh kartaoh DD ozołówki (JCL) zadania, w którym rea- 
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lizowany jest program. W przypadku taśm magnetyoznyoh pTOS Ttfi 
umożliwia odozytanie informaoji zawartyoh w wielu plikaob 
(file) voluminu opisanego za pomooą jednej karty DD, oo * 
padku metod dostępu dla taśm magnetyoznyoh w OS/360 jest do«^ 
istotne. Sposób współpraoy (interfaoe) programu ramowego * P*° 
gramami realizaoji, opróoz przekazania dokumentu do przet* 0 ' 
rżenia, przewiduje również* 


• przekazanie informaoji o strukturze i organlzaoji zbioru* 

• przekazanie informaoji zwrotnej o dokumencie opraoowany® * 

• przekazanie dyspozyoji programowi ramowemu oo do ozynn°^°* 
jakie ma wykonać* 

a. wypisać opraoowany dokument i podać następny, 

b. wypisać opraoowany dokument i nie podająo następnego 0 “ 
dać sterowanie, 

o. "przewinąć” n kolejnyoh dokumentów, 

d. zakońozyć praoę awaryjnie z powodu niezgodnośoi inT 01 ’"* 
oji wejśoiowej z zadaniami programu realizaoyjnego, 

e. zakońozyć praoę normalnie, 

f. przerwać współpraoę z danym programem realizaoyjny® * 
ewentualnie podjąć z następnym, 

. stf 0 ' 

• przekazanie programowi realizaoji informaoji o tym, a 0 . 
tura dokumentu niezgodna jest z wymaganiami odnośnie b u ' 
zbioru wyjśoiowego. Program realizaoji może poprawić 

lub zakońozyć praoę ze źle zdefiniowanym zbiorem wejśo* 0 
i przejść do następnego zbioru wejśoiowego lub zakońozy 
praoę, gdy źle zdefiniowano zbiór wyjśoiowy. 


Drugim realizowanym dooelowo programem ramowym jest 
będąoy logiozną kontynuaoją programu POPR i standardu 
ZAM 41. Ten program aktualizaoji tekstów zapieanyoh na n °^ 
kaoh sekwenoyjnyoh z założenia nie jest pomyślany jako 111 
pretator zawartośoi aktualizowany oh tekstów. Przewidywań® 
nim możliwość współpraoy z tymi samymi programami reali 2 ® 0 
oo i VWYD w dużym stopniu rozszerza jego możliwośoi. QP*° 
realizowanyoh w nim ozynnośoi aktualizaoji struktury f***^ 
nej oiągu dokumentów ozy znaków w ramaoh dokumentu (reoo 
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^zliwoóć wywołania programu realizaoji związanego z logicz- 
n 'ł etiuicturą aktualizowanego tekstu, rozszerza zakres jego 
‘°£liwości o czynności interpretacyjne. Ponadto nie oboiąża 
^Kraniowo programu ramowego, który realizuje tylko aktuali- 
** Q Ję fizy czną. 


^raoę taką można sobie na przykład wyobrazić następująoos 

pw 

Kram VPOPR przeprowadza fizyczną aktualizację tekstów a wy- 
w °lony p rzez niego program wymiany bezkontekstowej ciągów 
***** wymienia w aktualizowanych dokumentach pewne ciągi zna- 
na inne, przeprowadzając np. podstawianie konkretnych war- 
pod symbolicznie oznaozone parametry foraalne itp. 

Przewidujemy, że po oddaniu do eksploatacji programu VWYD 
^Kramów realizacyjnych, biblioteka tych ostatnioh szybko 
?W ^8 Z y się o programy redagujące wydruki dla ogólnie stoso- 
" rj ^ języków programowania jak ALGOL, FORTRAN, PL/1 i inne 
. o inne czynności związane z interpretacją logiczną zawar- 
1 dokumentów. 



ograćja logiczna 


o 

8 


^Próoz programów VPOPR i VWYD przetwarzających teksty, oprą- 
^weuie są w ZDO IMM programy do obsługi maszynowyoh nośników# 
r '° Programy! 

- program obsługi taśm magnetycznyoh, którego funkcje po¬ 
legają nat 


* s Prawdzaniu zapisu na TM zarówno pod względem poprawności 
^syoznej jak i zgodności zapisu ze standardem, 

% a P°rządzaniu wypisów zawartości TM poczynając od spisu pli- 
a kończąc na wypisie zawartości zadanyoh bloków 

dokumentów , 

^irytowaniu taśm magnetycznych, 

^ 0y, ielaniu taśm magnetycznych, 

1 t* 


a towaniu nośnika. 
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DIRAC - program obsługi urządzeń o bezpośrednim dostępie, ^ 
rego funkcje będą polegały nat 

• obsłudze zbiorów organizaoyjnyoh VT0C i SISCTLG umożliwić 
oej katalogowanie, usuwanie, zmiany nazwy, tworzenie logi° z 
nyoh struktur indeksowyoh itp. 

• produkowaniu wypisów zawartośoi voluminów dyskowy oh taki° b ^,, 
jaki VT0C i SYSCTLG, a wykazy zbiorów PO direotory, lisW 
mentów, fizycznej zawartości bloków, ścieżek i oylindró'*' 


• sporządzaniu kopii zbiorów lub voluminów, 

• produkowaniu wydruków typu dump z voluminów, 

• metrykowaniu i sprawdzaniu dysków. 


Integraoja logiozna tyoh programów oraz innyoh mniej z®* ^ 
sowanyoh w opraoowaniu polegać ma na tym, iż w odróżnieni 0 
programów UTILITIES OS/360 będą one miały jednolitą składni 
języka sterująoego oraz ujednolioone sterowanie za pomooą 
kart DD języka JCL. 


Nadmienić tu warto, że programy manipulaoyjne komunikuj 
się z operatorem (programistą) za pomooą wspólnego zesta* 0 
ujednoliconych komunikatów o jednolitej składni i z reguły 
gdy ma to sens praoują w dwóch reżimaoh: 


standardowym, polegająoym na interpretowaniu i wykonani 0 
kolejryoh zdań zestandaryzowanego języka sterująoego 


konwersacyjnym, polegająoym na kolejnym wykonywaniu p° 
wprowadzanyoh z konsoli systemowej jako odpowiedzi na 
dardowe komunikaty emitowane przez manipulatory. 


1 e« # ^ 

„W 


Przełąozenie z reżimu standardowego na konwersaoyjny 0 ^ 
wa się przez usunięoie karty DD o nazwie "DANE" z ciągu * 
JCL wywołującyoh dany program manipulacyjny- 
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«pec, 


6 ' ° ai AGNIĘTE EFEKTY 

/^Plwie* na tak wozesnym a tapla realizacji trudno konkretu 
lk E “ wlć o efektaoh, to niektóra z niob Już w ozaale wstępnej 
Ploataoji 1 uruchamiania można zauważyć! 


. .ola przez 4-5 manipulatorów zintegrowanych funkoji kil-< 
' naat u manipulatorów firmowyoh, a w przypadku taśm magnetyoz- 
^oh opraoowanie programu, który w bibliotaoa standardowej 
^360 opróoz funkoji metrykowania nie ma odpowiednika w ogó- 

**l 

Powadzenie reżimu konweraaoyJnago tak ważnego w praktyce 
• “ratorakleJ, gdzie wiele funkoji realizowany oh Jeat doraż- 
6 bez ozaau na przygotowanie programu atarująaago, 

1 ^^noiio 


IW 

*ię 


enie Języka steruJąaego praoą manipulatorów do tego 
Pola, iż programy aterująoe różnyoh manipulatorów różni* 


Powinny Jedynie treśoią a nie formą* Różnorodność formy 
^ : ezozególnie uoiążliwa przy korzystaniu z programów grupy 

, gdzie widać dużą pomysłowość programistów poszczą¬ 
cych programów w komplikowaniu składni Języka sterująoego, 

! 

r ° w ad^anie wspólnej grupy komunikatów dla wszystkioh mani- 
torów w przeciwieństwie do programów UTILITY, gdzie każdy 
t ^gramów emituje swe własne komunikaty nieraz Jednoznaczne 
K °ttUnikatami inny oh programów tej samej grupy. 

k 4 2 &końozenie stwierdzić należy, iż dopiero szeroka prakty- 
^t^^fikuje wyrażone wyżej poglądy i będzie bogatym źródłem 

, 'Wia a _ , . . - _ , _ j 


ltt i " iacl Qzeń w dalszej praoy nad programami manipulacyjnymi, 
U.^ c| * miejsoe w systemie oprogramowania EUO Jest przecież tak 

tQ tne. 
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0FTAHM3AUJW MHTamiPOBAHHtUC MAHMFm/IOHHŁfit IIPOrPAMM 


Pe3K)Me 

OymecTBeHHaH npoÓJiewia npa coshohuh óikSjimotckh CMCTewiHH* 
MaHimyjiauiioHHUx nporpaMM 3aKjima«TCH b KOJiHnecTBe u pa3H0- 
OdpaSMH MeTOflOB HX HCn0JIfc30BaHJlfl IipHMOM HX HOilCTBHH HeOflHO" 
npaTHO iioxojkh Apyr Ha upyra. 

B pa3padoTKe npencTaBjieHa unea nHTerpnpoBaHHnx MaHHfly^" 
TopoB, nosBOJWKJiuaH coKpaTHTt hhcjio MaHiuiyjiflUKOHHHx riporpa*® 1 
jio HecKOJitKHX, a Taicme yHM$HuwpoBaTB m6toh nx McnojiiaoBaH^ 
OniicuBacTCH KOHiienmwi nocTpoemiH rjiaBHoił nporpaMMu, BunoJi" 
HHiomett uiHpoKwe $yHKimui nyreM nu30Ba Monyjieft, peaumsyioimoc 
cneiuiajiH3HpoBaHHU0 sawann, npuneM rjiaBHaa nporpawMa h pe a " 
jni3yiQiiUie MOjayjni MoryT óhtł Hannoas w Ha pa3Hux H3UKax npo- 
rpaMMHpOBaHMH. 

OCHOBOS pU3paÓ0TKM CJiyjKHT npaKTMHeCKMii OnUT, HaKOnJieHHl^ 
upn oócjiyjKHBaHiiH MaiodecneneHHn MauuiHbi ZAM-41 h b xone p®' 
doT no cosnaHino dwÓJWOTeKH MaTOdecneneHHH b CHCTeMe ob/36 0, 

CONCEPT OF THE INTEGRATED UTILITIES 


.u< 

-*■rO l ‘ 


Summary 

A very important problem arising in establishing a library of 
tem Utilities is their number and varlety of ways of their use whi le 
their actions are often slmilar. 

The paper presents the example of integrated service program* 
ing their reduction to only a few as well as standardizatlon of c 0I,v ' 
The concept of main program design is discusaed. The program pl«y® ^ 
very important part by calling modules which parform specialized 
tions. 

. .. ęt° 

The main program and function modules can be written in vari° l, “^ 
grarnming languages, The paper is based on practice with the servi c ^ 0 
ZAM 41 Computer and with the establishing of software library of 
OS/}60 system. 


(ćj I nr. ty tui 
0?-0Vt- tfn- * • , 
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i podstawowego opisu. Zapewnia ona możliwość 
eri tyfikowania postaci źródłowej oprogramowania 
p 0( . J) °dstawie informacji włączanych do wynikowej 
Uw Ci °P r 0 Sramowania # J ak również eliminuje moż- 
0pr 0 ^ powstania rozbieżności między dokumentacją 
^ramowania a stanem faktycznym. Podstawą opra- 
Ją *U stały się # praktyczne doświadczenia wynika- 
Pracy przy serwisie oprogramowania maszyny 
* r oraz w trakcie tworzenia biblioteki opro- 
^°wania w systemie OS/360. 


Spis treści 




’ m *teriał źródłowy oprogramowania 
* St RUKTURA materiału źródłowego oprogramowania 

’ Bu D0WA plików źródłowych dla wyróżnionych klas elementów OPROGRAMO¬ 
WANIA 



Programy 
Moduły proste 


Teksty 

Makrorozkazy języka ASSEMBLER/360 
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WSTĘP 

W opraoowaniu opisano pewną konoepoję organizaoji bibli°~ 
teki oprogramowania możliwą do realizaoji na maszynaoh oyf* 0 ' 
wyoh średniej wielkośoi* Konoepoja ta jest wynikiem doświad" 
ożeń zebranyoh przy serwisie oprogramowania mas^rny Z AM 41 
oraz przy realizaoji biblioteki oprogramowania w systemie 
03/360. 

Celowo pominięto pewne szozegóły konkretnej realizaoji 
podkreślenia ogólnośoi opisanej organizaoji. 


i. materiał źródłowy oprogramowania 

Materiał źródłowy oprogramowania (MZO) - jest to ujedno**' 
oony i zapisany na maszynowyoh nośnikaoh informaoji (na ogd* 
taśmaoh magnetyoznyoh), zespół dokumentów opisująoyoh zaró*® 0 
w sensie ideowym jak i dokumentaoyjnym (faktyoznym) określ 0 ^ 
system oprogramowania. Wymaga się ponadto, aby dla konkretno 
go MZO była śoióle opisana teohnika jego aktuall 2 * 


o j i oraz prooedura przechodzenia od MZO do postaoi 


w r 


nikowej oprogramowania. Przez posta u 
wynikową oprogramowania rozumiemy taką jego postać w jakieś 
musi się ono znajdować w maszynie podozas eksploataoji syeto 
mu. W następnyoh paragrafach opisano realizaoję biblioteki 
wykorzystująoą jako podstawowy nośnik taśmę magnetyczną. 


2. STRUKTURA MATERIAŁU ŹRÓDŁOWEGO OPROGRAMOWANIA 

,rv v 

MZO zawarty jest na voluminaoh ź r ó d ł °" 
w y o h (VZ) . Voluminami źródłowymi są szpule taśmy magne" 
tyoznej, a zapisane na niej pliki nazywany plikami 
źródłowymi (PZ). 


Pliki źródłowe są 
pełną dokumentaoję 


zbiorami dokumentów tworząoyoh możli** 0 
elementów oprogram 0 




^pec * 


ORGANIZACJA Y.OLUMINÓW DOKUMENTACYJNYCH 


195 




* a (EO). Cechą elementu oprogramowania jest posła- 

(] m. 

n i e postaol wynikowej. 


°Pró 




oz właśoiwyoh plików źródłowyoh volumin źródłowy może 


®rać również tzw. fikcyjne pliki żró- 


®o w 


e zawierająoe jedynie dokumentaoję opisową oprogra- 


i nie pozostawiająoe śladu w postaoi wynikowej* Do te- 
J typu plików należy pierwszy plik każdego voluminu źródłowe- 
* J est to plik o nazwie "DATA". Służy on do ewidencjonowania 
” n wprowadzanych do voluminu źródłowego oraz jest nośnikiem 
' y o j i yoluminu źródłowego (EVZ) . 
voluminu źródłowego jest tekst trzyliterowy. Zwiększe¬ 


ni 

' 4 

h 




*»*4ł 


®VZ następuje zawsze w wypadku dokonania zmian w voluminie 


°wym. 


Zwartość pliku źródłowego podzielona jest na strony. 

^ S tyona jest to oiąg dokumentów pliku zaozynająoy się od do- 
zwanego znaoznikiem strony. Bu- 
0 * a *naoznika strony jest zależna od konkretnej realizaoji 
^Stamowania biblioteki MZO. Końoem strony jest poozątek 
następnej lub konieo pliku. 

. * Pliku źródłowym wyróżniamy następująoe ozęśoi, z których 
składa się z oałkowitej liozby stron (niektóre z tyoh 
mogą być puste )t 

S ^ r °na ewidencji zmian PZ 
% ^° 8 ^ać źródłowa EO 

/^•dury sterowania zadaniami (JCL - Job Control Language) 

% postaoi wynikowej EO (dane, program) 

, funkojonalny EO 

realizaoji EO 

U^ona ewidencji zmian PZ spełnia w nim funkcję podobną 
^ Pierwszy plik yoluminu źródłowego, a więc zawiera informa- 
ż* 0 dokonanych zmianach w PZ i jest nośnikiem edycji 
1 i k u źródłowego (EPZ). Edycja pliku źródłowe- 
j J*8t parą elementów trójznakowych, z których pierwszy poda- 
6 & tycję yoluminu źródłowego jaki powstał podczas ostatnich 
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poprawek danego pliku źródłowego, a drugi Jest liozbą trzy o?' 
frową wskazująoą ile razy ten plik był poprawiany. Drugi oz^ 
EPZ jest więo zwiększany o 1 w przypadku dokonywania zmian 
wewnątrz pliku źródłowego. Ten drugi ozłon nazwiemy 1 i o z ' 
niklem zmian PZ (LPZ) • Można więo zapisaó bud® 
wę EPZi 


<EPZ>i:= < EVZ > - <LPZ> 

Przykłady* AAB - 001, ABD - 015. 

Strony wohodząoe w skład pliku źródłowego posiadają e d 
oję strony (EST) skonstruowaną analogicznie do 
oji pliku źródłowego* 


<EST>::« <EPZ> - <LST> 

gdzie i pierwszy ozłon jast edyoją pliku źródłowego, który P° r 
stał podozas wprowadzania ostatnioh zmian na danej stronie* 
drugi ozłon jest lioznikiem zmian na stronie. 

Przykłady edyoji stron: 

AAA - 000 - 000, AXI - 029 - 013 

Należy tu zauważyć, że o ile ostatni ozłon edyoji strony 
zmienia sią w sposób regularny (o 1 przy każdej zmianie b&° 
ny), o tyle wyższe ozłony edyoji zmieniają się nie'regularn* 0 
ze względu na ozęstsze, na ogół, zmiany edyoji elementów ^ 
rzędny oh (plików, voluminów)« Istnieje zasada, że przy dok° 
waniu zmian w voluminie (pliku) edyoje niezmienianyoh pliK 0 * 
(stron) nie zmieniają się. 


Edyoja strony zawarta jest w dokumenoie rozpoozynająey® 

K 

stronę (znacznik strony)• Dokument ten zawiera również 
klasyfikująoy stronę jako element jednej z wymienionych ozś 
ci pliku źródłowego. 


Element oprogramowania zawarty w pliku źródłowym ma e 

przyporządkowaną edycję. Przyjmuje się, że edyoja 0 
mentu oprogramowania (EEO) równa się 
wyższej wartości drugiego członu (tzn. licznika zmian PZ) 0 



Spec. 
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°3l stron tworzących postać źródłową elementu oprogramowania. 
^y°da elementu oprogramowania winna być tak: wmontowana w pos- 
^ źródłową tego elementu, aby zawsze przechodziła do jego 
P°staci wynikowej. Sposób wmontowania EEO może być różny dla 
r< ^ ż nych typów EO. 

Postać źródłowa EO jest to formalny zapis elementu oprogra- 
010 Wania przetwarzany za pomooą odpowiednich środków programo- 
(np. translatorów odpowiednich Języków) na postać wyniko- 

EO. 

Pi^cedury ste rowania zadaniami (JCL) wohodząoe w skład pli- 
^ źródłowego opisują różnego rodzaju transformaoje wykonywa- 
r,J fta elemencie oprogramowania, szozególnie sposób przekształ¬ 
cała postaci źródłowej tego elementu na Jego postać wynikową. 
^°PUszoza się dowolną liczbę takioh prooedur w jednym pliku 
^dłowym. 

Opis funkcjonalny przeznaozony jest dla potencjalnego użyt- 
^ 0<v hika EO i powinien zawierać informaoje opracowane pod tym 

°Pis realizacji przeznaczony jest dla programisty wprowadza¬ 
nej zmiany do istniejącego EO. Winien tu być zawarty opis 
Władnej budowy wewnętrznej elementu oprogramowania i ewentu- 
^•&le współdziałanie między poszczególnymi częściami elementu. 

T est postaoi wynikowej EO określa metodę sprawdzenia po- 
^ewiuiiśoi nowo otrzymanej wersji elementu oprogramowania, 
lotnym wymaganiem jest nadanie tej części pliku źródłowego 
^taci umożliwiającej automatyozne sprawdzenie poprawności 
^ Se z U( j z iału programisty. 


5 ‘ Fulowa plików źródłowych dla wyróżnionych klas elementów 
oprogramowania 

Pewne szczegóły budowy plików źródłowych są różne dla róż- 
typów elementów oprogramowania. Wprowadzimy zatem podział 
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elementów oprogramowania na klasy z punktu widzenia organizm" 
oji ioh dokumentacji. 

Poniżej będą omówione przykładowe dwie klasy elementów opr 0 ' 
gramowania: 

• klasa TEKSTÓW 

• klasa PROGRAMÓW 

Należy się spodziewać, że w miarę rozwoju prao dokumenta- 
oyjnyoh będą się pojawiać nowe kategorie elementów oprograo 0 ' 
wania, dla który oh trzeba będzie określać konkretne strukturt 
plików żródłowyoh. Winny one Jednak zawsze spełniać wymaga* 1 *® 
ogólne określone w p. 2. 


3.1. Teksty 

Tekstami nazywamy te elementy oprogramowania, który oh P 00 ' 
taó wynikowa Jest zbudowana z dokumentów stanowiąoyoh posta^ 
źródłową EO w pliku źródłowym. Można więo powiedzieć, że 
klasa elementów oprogramowania ulega przekształoeniu toźsaO 0 * 
oiowemu podozas przeohodzenia z postaoi źródłowej do wynik 0 ' 
wej. Zmianie ulega Jedynie organizaoja zbioru, z sekwenoyd ne 
go pliku źródłowego na bibliotekę dostosowaną do wymagań k 0 ° 
krotnego systemu operacyjnego dla postaoi wynikowej. 

Obeonie nie można określić szozegółowyoh wymagań dla 
kioh możliwyoh rodzajów tekstów. Zasadniozo żąda się, aby 
dy z nioh zawierał informaoje o własnej edycji podaną w 8P° 
umożliwiająoy użytkownikowi identyfikaoję, tzn* bez odwoły*® 
nia się do postaoi źródłowej. 

W następnym punkoie podane są przykładowe wymagania dl* 
tekstów będąoyoh makrorozkazami w Języku 
SEMBLER/360. 
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^•1* Makrorozkazy języka ASSEMBLER/560 

Każdy z makrorozkazów posiada nazwę, będącą jednocześnie 
a &2wą elementu zawierającego ten makrorozkaz w określonej 
^blioteoe. 

W trakoie rozwijania makrorozkazu winno być zapewnione wy¬ 
zerowanie zdania, które Jest komentarzem w Języku ASSEMBLER, 
P°^ a Jąoego edycję makrorozkazu. 

W częśoi opisowej, niezależnie od zagadnień fuńkojonalnyoh 
p0w lnny być określone następująoe informaoje: 

* n azwa makrorozkazu 

* biblioteka - nazwa zbioru typu partitioned, w którym znajdu¬ 
je się postać wynikowa makrorozkazu 

* - informaoja określa, do którego z typów (łącznik, pie- 
° z ątka, tablioa, podprogram) zaliozany Jest makrorozkaz. 

Wśród procedur sterowania zadaniami (JCL) musi wystąpić 
Pt °oedura określająoa sposób skopiowania postaci źródłowej EO 
4 ° Jej postaci wynikowej. Oprócz tej procedur dla makrorozka- 
typu "podprogram", mogą wystąpić dodatkowo prooedury 
^eślająoe różne sposoby generowania pewny oh szozególnyoh 
*®*8Ji podprogramu, przeohowywanyoh w biblioteoe w postaoi 
^dułdw typu "load". W takim przypadku szozegółowe informa- 
0 de o parametraoh generowania oraz o bibliotekaoh, w któiyoh 
^ Moduły i ioh nazwy będą umieszozone, winny być zawarte w 
Nśoi opisowej odpowiednioh elementów oprogramowania. 


Programami nabywamy te elementy oprogramowania, których 
P ° 8 bać wynikową uzyskujemy po przekształceniu ioh za pomocą 
^siatorów języków programowania. Postać wynikowa może 
1(1 umieszczana w bibliotece dostosowanej do wymagań systemu 
^aoyjnego lub wyprowadzana na odpowiednioh nośnikaoh da- 
^h. ogólnym wymaganiem dla tej klasy EO Jest posiadanie in- 
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formacji, zawartyoh w postaoi wynikowej, określający oh nazw? 
EO i jego edyoję. 

Sposób umieszozania tyoh informaoji w postaoi wynikowej i 
jak również dodatkowe wymagania dokumentacyjne w odniesieniu 
do pozostalyoh ozęśoi pliku źródłowego są uzależnione od uży - 
tego języka programowania i systemu operaoyjnego. 

Przykładowo podamy wymagania dla pewnej grupy programów, 
nazwanej modułami prostymi, istniejąoej w 
systemie operaoyjnym 0S/360. 


J.2.1. Moduły proste 

Moduły proste są to programy napisane w dowolnym Języku V* 0 ' 
gramowania, Ioh postaoią wynikową jest moduł t y P u 

V i 

”1 o a d" będąoego elementem określonej b i b 1 i o t • ' 
(tzn. skatalogowanego zbioru typu "partitioned"). Z każdy® * 
takioh programów związane są dwa następująoe symbole: 


a) nazwa biblioteczna - zmienna określ®*^ 
oa punkt wejścia do programu oraz będąoa nazwą elementu 
blioteki zawierająoego postać wynikową tego elementu OP* 0 ^ 
gramowania. Symbol ten pozostaje niezmienny prsgr koleje 
aktualizacjach programu, 

b) zmienna edycyjna - symbol 8 znakowy, 
rym 5 pierwszyoh znaków określa symbol e w i d 
o y j n y elementu oprogramowania, zaś 3 ostatnie 
cyframi dziesiętnymi) - edycję elementu* 
druga ozęść symbolu zmienia się więo przy każdej popraw 00 
postaoi źródłowej EO. 


e * 




Edycja elementu (liczba wyznaczona przez 3 ostatnie zDflA t 
zmiennej edycyjnej) jest również "wmontowana” w sam ele®° 0 ^ 
w postaci pierwszego rozkazu modułu, którym Jest rozkaz N 
gdzie x jest edyoją EO. 

W ozęśoi opisowej modułów prostych podane są następują 00 
ioh charakterystyki: 
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% * y p. Typem może być program - gdy moduł jest 
'Zwoływany samodzielnie (za pomocą zdania EXEC) , lub pod- 
Pr ogram - gdy nie jest przystosowany do tego, aby 
^ : sterowanym przez zdania JCL, 


*^°stać biblioteczna. Może być określona 
moduł otwarty - gdy moduł typu "load" 
Osiada nie rozwiązane odwołania zewnętrzne i jego wykorzys- 
^ at iie musi być poprzedzone opracowaniem go przez Linkage- 
E(J itor. Do takiego modułu nie można szczególnie odwoływać 
®i§ za pomooą makrorozkazów LINĘ, XCTŁ, 


' * a rtość moduł zamknięty oznaoza, że w pos¬ 
toi wynikowej moduł może być wykonywany. Posiada "rozwiąza- 
lJe " wszystkie odwołania zewnętrzne i można odwoływać się do 
*1*60 za pomooą makrorozkazów LINK, XCTL, 

'biblioteka - określa nazwę zbioru partitioned, w 
^ry,,, znajduje się postać wynikowa tego elementu* 




wszystkioh modułaoh prostyoh zmienna edycyjna jest zmien- 
2Q wnętrzną programu, a więc może być odozytana z wydruku pro- 
°Wanego przez Linkage-Editor. W modułaoh typu program, któ- 


ł ‘ w normalnym wykorzystywaniu nie podaje się do przetwarzania 
. ^ge-Editorowi, zmienna edycyjna jest również dodatkową naz- 
^ *°dułu. Może więc być również odczytana z wydruku directoiy 
biedniej biblioteki. 


. Moduły proste zawierają jedną procedurę sterowania zadania- 
^ ^CL). Jest ona zbiorem zdań JCL określającym sposob prze¬ 
gania postaci źródłowej EO na jego postać wynikową. 
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0FTAM3AIJłtH ^AllJIOB MATOEECIIE^IEffl® 
Pe3me 


CymecTBeHHofl: npoÓJiSMOft npH C03^aHnii (5ojimihx chctsm, b tom 
HHCJie u onepanjiOHHŁDc cncTew f HBjiHeTCH odocHOBamie onepemn# 
BapuaHTOB CHCT6MH H 6© 3JieMeHT0B. B pa3paÓ0TKe npencTaBJiH- 
eTCH MeTOfl xpaHeHHH OHepemmx BapnaHTOB MaTodecneneHHii, 
BKJimaH $opMy oiipe^ejieHua nx M3j;aHKłi u ocHOBHoro ornacaHiŁtf* 
3T0T MeTOfl n03B0JIEeT HfleHTH^IimipOBaTB HCXOBHLlfi BHfl MaTOdeO- 
neneHiiH Ha ocHOBe HH^pMaiiHH^KjnoHaeMofi b OKOHHaTejn>HHfl Btffl 
nporpaMM f a TaiOKe HcmnonaeT bo3mojkhoctb noHBjiewsi pacxox,neH2fl ^ 
amy .noKyweHTamiefi MaTodecneneHUK u (^aKTunec khm cocTOHHneM«0 c ^ 
boS Tpy^a cjpht npaKTuraecKHii oiiht, HaKonjieHHHft iipn odcjiy~ 
BMBaHHH MaTodecneHeHHH Mannami zam-41 h b xo,n;e paćoT no co3- 
flamno dnÓJMOTeicii MaTodecneneHna b cucTeMe os/360• 


THE ORGANIZATION OF SOFTWARE DOCUMENTATION YOLUMES 


Summary 

While creating large software systems # including the operating 
tems the documentation of successiye yersions of such a system and ^ 
elements is a vital problem* This paper presents a rnethod of storl^g 
the successiye yersions of the software together with a form of tb® ir 
edition Identification and basie description. The method enables id 0X1 
tification of source codę yersion from which given module was obtal 0 
ed« 

The method gives also a possibility of elimlnation of contrcy® 1 *'’^ 
sions between the software documentation and the software it descri b ® 

The paper bases on practice obtained during the service of ZAM W 
software and on the creation of software library on the QS/360 sy fil 


(c) Instytut Maszyn Matematycznych 
02-078 Warszawa , ul. Krzywickiego JA 
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WIELODOSTĘPNY SYSTEM KGNWERSACYJNY MACS 
Część I. Projekt systemu operacyjnego 

Jerzy KARCZEWSKI 
Centrum Obliczeniowe PAN 
Pracę złożono 10.1.1974 


opracowaniu przedstawiono sohematy blokowe 
J a J*ażniejszych fragmentów systemu operacyjnego 
godzącego w skład systemu MACS (Multi-Access 
Onversational System), który jest eksperymen- 
Haym wielodostępnym systemem konwersacyjnym 
* maszyny ODRA 1204. Omówiono również sposób 
t rac y systemu operacyjnego przy narzuconym de- 
^ %r minizmie. System MACS realizuje wielodostęp- 
ość wykorzystując system przerwań zarówno ukła- 
° w yoh jak i programowych. Omawiając system 
£ r *erwaó szczególną uwagę poświęcono wpływowi 
^°*zcz0gólnych zdarzeń na tryb pracy systemu, 
^wykończeniu om ^wiono wpływ specyfiki maszyny 
n ** 1204 oraz przyjętej konfiguraoji systemu 
* projekt systemu operacyjnego. 


Spis treści 


1 * Wstęp 
ZAŁOŻENIA 
GŁÓWNE POSTULATY 

L 

• przydział procesora i system przerwań 
schematy systemu operacyjnego 
zakończenie 
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1. WSTĘP 

MACS - Multi Aoooss ConveraatlonaX System jest eksporym 00 " 
talnym wielodostępnym systemem konwersaoyjnym dla maszyny 
ODRA 1204. System ten, zrealizowany w Centrum Obliożeniony® 
PAN, umożliwia jednoozesną praoę ozterem użytkownikom. Każde 
staoja wyposażona jest w monitor i perforator, a dwie z ni° b 
posiadają ponadto ozytnik taśmy papierowej. System operaoy)^' 
(SO) współpraouje z "ozystym" translatorem języka konwersaojJ 
nego MARO-2. Na rys. 1 przedstawiona została konfiguraoja *7 
temu. 


2. ZAŁOŻENIA 

Choemy tu przedstawić projekt systemu operaoyjnego dla 8 ? 0 
temu MACS, a dokładniej mówiąo ozęóć dotyoząoą programów 
zorozyoh. Zanim jednak przystąpimy do omówienia zasad 
nia SO, zastanowimy się nad tymi oeohami maszyn oyfrowyoU 
1204, które wpłynęły na konoepoję SO. ODRA 1204 nie jea* 5 * ^ 
zasadzie przewidziana do wykorzystywania w systemaoh wiel°d°^ 
tępnyoh głównie z uwagi na zbyt małą pojemność pamięoi °P 0r ®j, 
oyjnej, uniemożliwiającą podział jej między‘przynajmniej 
użytkowników. Maksymalne pole jakie można by przydzielić P 
założeniu jednoozesnego podziału pamięoi między co najmni®*^ 

2 użytkowników wyniosłoby 4 K. Pole takie uznaliśmy za 
małe. Przyjęliśmy więo zasadę, że w danej ohwlli w parnię®* 
operaoyjnej (PO) znajdować się może pole jednego użytkown 
o wymiarze 8 K. Głównym problemem stało się więo, wobeo 
niecznośoi dokonywania wymian bębnowyoh po każdej zmiani® 
działu prooesora oentralnego, zminimalizowanie strat oza® ^ 
z tym związanyoh. Przez wymianę bębnową rozumieć będziemy ^ 
słanie pola użytkownika, któremu skońozył się przydział P r g 
sora oentralnego (PC) do pamięoi bębnowej (PB) i przeni® 8 * 0 ^, 
z PB do PO pola użytkownika, któremu zostanie przydzielony^ 
Sam ozas wymian bębnowyoh jest znaozny (średni ozas oozek 
nia na obrót bębna) wynosi 20 ma, szybkość transmisji - ^ 

12000 słów/s.Dlatego minimalizaoja ozasu reakcji systemu 
nana została z uwagi nat 
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• minimalizaoję liozby wymian bębnowych, 

• minimalizaoję ozasu działania programów SO. 


3. GŁÓWNE POSTULAM 

Podamy teraz i uzasadnimy główne postulaty, na który oh °P ar 
ta została konoepoja realizaojl SO: 

I. Natyohmiastowa obsługa przerwań 

Obsługa przerwań związanyoh z szeregowaniem, transmisjami 
oraz błędami nie niszozącymi systemu odbywa się natychmiast P° 
przyjęciu przerwania. Rozwiązania takie przyjęto ze wzglę du Ilft 
krótki ozas obsługi przerwań oraz uproszczenie dzięki temu 
działania szeregowania. Uniknięto w ten sposób konieoznośoi 
tworzenia kolejki przerwań i programów taką kolejkę analiz 0 *^ 
oyoh. 


II. Trzy tryby pracy systemu operaoyjnego 

Tryb pracy systemu uzależniony jest od wykorzystania 
i tak wyróżniamy: 


• pracę użytkownika 

• praoę SO 

• testowanie systemu (przede wszystkim zliozanie ozasu 
użyteoznego" PC). 


Każdorazowa zmiana trybu wiąże się z odpowiednim ustawi 0 


programowego wskaźnika trybu praoy. Upraszoza się dzięki 


tem 11 

reakcje na zdarzenia występująoe podozas praoy SO. WszystK* 0 ^ 
zmiany trybu praoy są śoiśle określone i występują tylko * 
mentach wyznaozanyoh przez praoę SO (patrz opis rys. 2). 


III. Oohrona przed przerwaniami fragmentu programu szereg' 
nia realizująoego aktywowanie zadań 

Zdarzenia związane ze zgłoszeniem się zadań do aktywo 


o**' 


w 


i* 


(np. naciśnięoie klawisza ZO na pulpioie modułu monitora P 
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Praca użytkownika TtitomU 

SyiUw 



A.B.C.D.S.f wyklucsają alf najemnie 

ZekoAcs^nle pracy SO powoduje katdoraaowo salaaf trybu pracy 
* pracy 90 aa pracę użytkownika lub testowania eysteau. 

Rys. 2. Ogólny schemat działania SO 
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użytkownika) są losowe. W oelu uniknięcia możliwości nałożeń 9 
się tyoh zdarzeń w ozasie (zgłoszenie się następnego zadania 
do aktywowania z innej lub nawet tej samej staoji przed ukoń- 
ozeniem aktywowania zadania uprzednio zgłoszonego) odpowie* 11 * 
fragment programu szeregowania wykonywany jest pod oohroną 
przed przerwaniami. Fragment ten realizuje aktywowanie zada 0 * 9 ' 
ozas jego wykonania jest tak krótki, że wzięoie go pod oobron^ 
przed przerwaniami nie powoduje zakłóoeń w praoy SO. DziS^* 
mu uniknięto konieoznośoi tworzenia kolejki zgłoszeń do pr°8 r9 
mu szeregowania i konieoznośoi oohrony programu szeregowania 
przed następnym wejśoiem do niego. 

IV. Kolejkowanie 

W SO systemu MACS kolejkowanie zadań odbywa się zgodni* 
z regulaminem FIFO. 

Ze względu na małą liozbę zadań mogący oh byó jednooześni* 
ozynnymi (4) kolejka ma następująoą postać« 

1) liozba zadań w kolejoe 

2) pierwsze zadanie (numer zadania) 

3) drugie zadanie (numer zadania) 

4) trzeoie zadanie (numer zadania) 

5) ozwarte zadanie (numer zadania) 

yta" 

Jeśli w kolejoe jest mniej niż cztery zadania, to poz ^ a j 
łe pozyoje są wyzerowane. Operaoje wykonywane na tak zbud°^ 
kolejoe (dołąozenle zadania do kolejki, usunięoie zadania ^ 
kolejkit przesunięoia oykliozne zadań - pierwsze na lconia ° ofl ^ 
sprawdzanie ozy dane zadanie znajduje się w kolejoe) P 
te i nie wymagają dużo ozasu (kilka operaoji maszynowych 1 * 


4. PRZYDZIAŁ PROCESORA I SYSTEM PRZERWAŃ 

Zanim przystąpimy do omówienia sohematów SO, zwróćmy 
oze uwagę na zasadę przydzielania PC poszczególnym zadań 
oraz system przerwań. 

400 

Jak już powiedzieliśmy jednym z ważniejszych problem** ^ 
zminimalizowanie liozby wymian bębnowyoh, pod warunkiem, 


• • • 
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^ wydłuży to czasu reakoji systemu. Przyjęliśmy następującą 
* a sadę: udostępniamy użytkownikowi PC tak długo, jak długo nie 
*P*ywa to ujemnie na ozas reakcji systemu. Polega to na tym, 
ie SO zaohowuje się oały ozas tak, jak gdyby było oztereoh 
Ui ytkowników w kolejoe. Drugim ważnym aspektem jest system 
Przerwań. Wykorzystaliśmy zarówno przerwania układowe jak i 
^Bramowe. Omówimy najważniejsze z nich, wskazująo jednooześ- 
na rolę jaką pełnią w funkcjonowaniu SO. 

1 

• Przerwania układowe 
• przerwanie ozasomierzą, 

Częstotliwość przerwań ozasomierza uzależniona jest od try- 
Praoy systemu. 

™ trybie pracy SO zależy nam na tym, aby przerwania nastę- 
^°Wały najrzadziej, gdyż wydłużają ozas praoy SO (przerwa- 
*** oo 640 ms) . 


W trybie pracy użytkownika przerwania wyznaczają długość 
^ontu ozasu przydzielania PC użytkownikowi. Na kwant ozasu 
biadają się 2 przerwania, ożyli może on wynosić od 4 ms do 
s. Długość kwantu ozasu może być każdorazowo zmieniona 
inicjowaniu praoy systemu (rozpoozęoie nowego seansu pra- 
Zmiana długości kwantu ozasu będzie dokonywana, jeśli ze- 
statystyki wykażą, że zwiększy się dzięki temu efektyw- 
systemu. 


W trybie praoy polegającym na testowaniu systemu zależy nam 
*** jak najozęstszyoh przerwaniaoh, gdyż umożliwia to szybkie 
t8a gowanie na wydarzenia zaohodząoe w systemie (przerwanie co 

* *s). 


* przerwania monitorowe. 

Informują o praoy monitorów (transmisje monitorowe, błędy 
^^itorów), 

• przerwania urządzeń zewnętrznych: czytniki i perforatory, 
Informują o pracy urządzeń zewnętrznych (transmisje i błę- 

^ Urządzeń) , 


212 


Jerzy KARCZEWSKI 


• przerwania związane z pracą bębna magnetycznego, 
Informują o przebiegu transmisji bębnowych oraz o błędach 

bębna. 

2. Przerwania programowe 

• zawieszenie zadania, 

Zawieszenie zadania następuje w wyniku wykonania kolejni 0 
zdania programu użytkownika. Zadanie jest zawieszone od mom 011 
tu wypisania przez SO znaku "x" na monitorze. Jest to stan 
oczekiwania na wprowadzenie przez użytkownika następnego 
nia. 


• uśpienie zadania, 

Uśpienie zadania następuje w wyniku wykonania przez SO 
instrukcji STOP wprowadzonej przez użytkownika. 

• usunięoie zadania, 

Usunięcie zadania następuje w wyniku wykonania przez SO 
instrukcji CANCEL wprowadzonej przez użytkownika. 


5. SCHEMATY SYSTEMU OPERACYJNEGO 


Na rys. 2 przedstawiono schemat działania SO. Warto pod^i 0 
lić, że wejśoie do programów SO może nastąpić w wyniku wzaj 0)ir 
nie wykluozająoych się sytuaoji. Testowanie wyklucza prao? 
użytkownika. Zawieszenie, uśpienie, usunięoie wykluczają 
wzajemnie, jak również wykluczają możliwość dojśoia do 
kwantu ozasu. Wejśoie do programów systemu operacyjnego p° 
końozeniu identyfikacji związane jest z konieoznośoią przy® 
towania pola dla użytkownika rozpoczynającego pracę w MARO'^ 
Sama identyfikacja nie wymaga przyporządkowywania użytkowo 
wi pola. Postulat minimalizacji liozby wymian bębnowych 
determinizm SO osiągnięto przez aktywowanie zadania tylko 
jednym określonym momencie wykonywania programów systemu 0 
raoyjnego. Sprawia to, że moment dołączenia zadania do kol 0 ^ 
ki zadań czekających na PC jest opóźniony w stosunku do 
tu zgłoszenia się. Jednak z punktu widzenia użytkownika oV ^ 
nienie to nie występuje, gdyż dołąozenie wykonywane jest 


V 



2 
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8lb y °n otrzymać przydział PC. Na zakońozenie podany jest 
8otl emat aktywowania (iys. J) . 



Rys. 3- Aktywowanie 

Zakończenie 

Wyjęta konfiguracja systemu oraz speoyfika EMC ODRA 1204 

^ynęiy w zasadniczy sposób na projekt systemu operacyjnego. 

8w iająo projekt systemu dużo uwagi poświęoiliśiiy sposobowi 

^tycznego zminimalizowania konsekwencji wynikających z ogra¬ 

cie 

,? ^n sprzętowych. Do systemu włączony został bogaty aparat 
ironia statystyk, które mamy nadzieję, wykażą słuszność 
Wyjętej konfiguraaji i projektu BO z punktu widzenia efektyw- 
^ systemu. 
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CMCTEMA C PA3JIEJEEH11M BPMEHM TMA "B0I1P0G-0TBET" MACS 
'iACTŁ I. IIPOEKT OIIEPAUHOHHOii CMCTEMbl 

Pe3K)Me 


MACS - Multi Aoc3bs Corweraational Syotem pa3padOTaHfl 
BHHHCJiHTe^BHHM ueHTpoM I1AH min 3BM ODR A-1204. Ha npoeKTapO- 
BaHne 3T0ft cucTeMU oaeHB (JojiBMoe bjihhhhc 0Ka3aziH ffBa $aKTOp£ 

1. JŁttHTe^BHoe BpeMH oÓMeHa 3anaa Mesuy onepaTMBHoM na- 
MflTBK) H óapaóaHHUM HEKOIIMTe JieM i 

2. HeB03M0KH0CTB pacnpe,ne.neHHH onepaTHBHoit naMHTH Me«ny 
XOTfl ÓH UByMH B0JIB30BaTejIHMH (CJHMIKOM MaJIEH 6 MK 0 CTŁ). 

B CBH3H c 3THM rjiaBHOil npo&ieMOii npw npoeKTapoBaHaa oKa- 
38JiaCB MHHHMH3amiH Bp6M6HH HSfiCTBUS OnepaiBlOHHOJł CHCTeMU. 

3to TpeóoBamie BunojineHO nyreM pea^H3aujiH cjienyiomHx nocTy- 

jiaTOB: 

- npnHHTHfl caMHX npocThoc penieraiił c tohkh 3pemw MauiaHHofl 
peajiH3aiiHii(BpeMJi neftcTBaa); 

- npHHHTiw OMeHB CTpororo neTepMHHH 3 Ma b M3MeHeHHKX no- 
pajma paóoTU onepauaoHHoJi cacTeMH( paóoTa nojiB 3 OBaT 0 Afl> 
padoTa onepaimoHHOfl CHCTeMH, npoBepKa. cacTeMU) mh - 
HaMa3aaaa KoaaaecTBa HeodxonaMŁa accjieflOBaHaft b peaK- 
ujihx cacTeMU Ha npoacxojyimHe HBJieHaa. 

B Tpy^e npencTaBJieHa óaoK-cxeMa caMux rjiaBnux aacTeft 
onepaiiaoHHolt cacTeMti. OnepaiiaoHHafl cacTewia MACS peanasyeT 
pa 3 R,ejieHae BpeMeHM Ha ocHOBe cacTeMU TexHHHecKax a nporpaM- 
mhhx npepuBaanii. 

lipa odcyiKneHaa npo&ieMH npepuBaHaft ocoóeHHoe BmiManae yA e 
jiaeTCH bjuihhhk) 0T,nejiBHiix HBJieHań Ha nopfluoK paóora onepa- 
UHOHHOft CaCTSMH. 

B 3aiuiK)HeHae oócpmaeTCH BjnwHae cneuH$aHecKax cboMctb 
Mamami ODRA-1204 a ripamiTOil KOH$arypaujiH Ha npoeKT onepa- 
uhohhoH cacTeMH. 
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4 HULt XACCESS conversational system macs 

1. THE OPERATING SYSTEM DESIGN 



°bft 

•nc 

1 ) 


^ACS - Multi-Access Conversational System has been implemented on the 
’ 1204 Computer in Computation Centre of the Polish Academy of Sol- 
Two following facts influenced the designi 

exchange time between core and drum memory, 

00 Bmall core memory to be shared among even two usera* 


Th a 


k -«i6e factors caused t^at the main design problem was to minim&lize 
f oł of the operating systemie work. The solubion is based on two 

' l0 wing postulatesi 


1 ) 


°^°osing the fastest Solutions to be implemented, 

^aforcing a Tery strong determinizm in changes of the system's modes 
^se r ' s activity f operating system activity, testing) to minimalize 
ne °®8sary scanning in the system activity. 


hi * 0w diagrams of the main operating system programs are shown. The 
interrupts and ertracodes are discussed with respect to the 
i^l. v ^access system implementation. A special attention is paid to the 
lu *nce of various events on the system work. 



a conclusion, the influence of characteristic features of 
***• on the operating system ia mentioned. 


the 


% 
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WIELODOSTĘPNY SYSTEM K0NWEB5ACYJNY MACS 
Część II. Obsługa wejść-wyjść 

Alina RUSZKOWSKA 
Centrum Obliczeniowe PAN 
Pracę złoiono 10.1.1974 


°Pracowaniu podano opis funkcjonalny 1 3trukturę 
^®temu MACS # zrealizowanego w Centrum Obllozenio- 
p AN na EMC ODRA 1204. MACS może być wykorzysty- 
w ośrodkach wyposażonych w EMC ODRA 1204 z 
i U b więcej jednostkami pamięci bębnowej 1 
‘Jarema stacjami, dla których wyposażeniem podsta¬ 
wy® je 8 t monitor, a opcjonalnym perforator i 
^ Walk taśmy papierowej. W oplBie struktury syste- 
% J szczególną uwagę zwrócono na wpływ ograniczeń 
Pr *9tovych na budowę systemu* 


Spis treści 

Wstęp 

• KONFIGURACJA sprzętu 
OPIS FUNKCJONALNY 

• struktura systemu 
'■'nioski 

^•ratura 


Wstęp 

Mawiany system bazuje na języku konwersaoyjnym MARO-2. 

^ “B pozwala na rozwiązywanie problemów naukowo-technicznyoh 
^^bie konwersaoy jnym, oo jest niezwykle oenne w przypadku 
"^konywania niewielkich obliczeń. Dwa tryby wykonywania in- 

Sł- 

ru koji języka MARO-2, programowy i natychmiastowy, pozwą- 
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łają w łatwy sposób pisać, uruohamiać 1 wykonywać programy 
użytkowe. 

Celem niniejszego opraoowania jest opis funkojonalny i str*^' 
tura systemu UACS. W pierwszej kolejnośoi omówiona będzie kon- 
figuraoja sprzętu. 


2. KONFIGURACJA SPRZĘTU 

Jak powszechnie wiadomo, koszt oprogramowania sprzętu li° z ^"" 
oego jest ooraz wyższy i w przypadku dużyoh systemów liozą®? 0 * 1 
znaoznie przewyższa koszt samego sprzętu. W związku z tym 
wzrasta znaozenie oprogramowania. Można zaobserwować tendenoJS 
do wykorzystywania wykonanego dotyohozas oprogramowania przy 
projektowaniu nowyoh systemów oprogramowania dla tego sameg 0 
sprzętu. W naszym przypadku, ze względu na brak oprogramowa' 
nia EMC ODRA 1204, które dałoby się ohooiaż fragmentaryczni® 
wykorzystać podozas realizaoji systemu MACS, postanowiono P rZ ^ 
najmniej nie zmieniać standardowego zestawu sprzętu, aby ®ot** 
wa była praoa w dotyohozas wykonany oh systemaoh oprogramowa 0 **' 
W konsekwenoji zestaw sprzętu wykorzystywany przez system 
stanowi rozszerzenie zestawu standardowego o urządzenia wej^ 0 ** 
wyjśoia umożliwiająoe jednoozesną praoę ozterem użytkownik 0 ® 
praoującym przy oztereoh staojaoh systemu. Staoją systemu 
wamy zestaw urządzeń, wejśoia-wyjśoia oddanyoh do dyspozyoji 
użytkownika na okres seansu jego pracy z systemem*. Podstawo'*? 81 
urządzeniem staoji jest monitor, dodatkowym - czytnik i P® r ^ <r> 
rator taśmy papierowej. Systemową informaoję o wyposażeniu fits 
oji w urządzenia dodatkowe aktualizuje operator odpowiednik 
instrukoją. Ta informaoja decyduje o możliwośoi użycia urzk^ 2 * 
nia podozas seansu użytkownika. 

Zestaw, połąozenia i funkoje poszozególnyoh elementów 0P r 
tu praoująoego w Centrum Obliozeniowym PAN obrazuje rys* 

■ Seansem pracy użytkownika nazywamy okras czasu, w którym użytkował* 
dostęp do systemu. 



***• Spoć. 
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Zestaw składa się z następująoyob elementów; 

1. jednostki ary tmetyozno-logioznej EMC ODRA 1204, 

2. bloku pamięoi operaoyjnej o pojemnośoi 165 słów, 

3. dwóob kanałów przesyłania informaojit 

kanału przesyłania słów (KPS) i kanału przesyłania znaków 
(KPZ), 

4. oztereob jednostek pamięoi pomooniozej (bębnowej) o poje®' 
nośoi 64K słów każda, podłąozonyob szeregowo do KPZ, 

5. oztereob monitorów - podstawowego wyposażenia każdej staoJ 1 
- podłąozonyob do EPS, 

6. dwóob ozytników taśmy papierowej ńtanowiąoyob wyposażeni® 
staoji o nr nr 1 i 2. Czytnik staoji 1 jest podłąozony do 
KPS, ozytnik staoji 2 do EPZ, 

7. oztereob perforatorów taśmy papierowej podłąozonyob do EPS 
przez jeden moduł perforatora. 

Ponieważ monitozy Optima, które stanowią podstawowe wyp 06 *" 
żenie poszozególnyoh staoji systemu, nie są dostosowane do 
cy w systemie konwersaoyjnym, podłąozono je do kanału przesyp 
nia informaoji w sposób zmodyfikowany, co jest widoozne na 
rys. 1. Dotyczy to monitorów staoji 2, 3 i 4. I tak informa°d fl 
pomiędzy monitorami a pamięoią operaoyjną przesyłane są prz 00 
KPS, natomiast sygnały przerwań poobodząoe od urządzeń są P 1 ** 
syłane do koordynatora kanałów w miejsoe sygnałów przerwań P 0 ”" 
obodząoyoh od niewykorzystanyob kanałów. W ten sposób infoi®® 
oja o przyozynie przerwania zgłoszonego przez urządzenie ’ 100t 
rozszyfrowywana przez samo zgłoszenie przerwania i nie wyma® 0 
analizy programowej, niezbędnej przy podłąozeniu typowym. 

Właśoiwośoi zastosowanyob monitorów podyktowały także 
dę transmisji po jednym znaku w KPS pomiędzy pamięoią opera 0 ? 1 
ną a ws^stkimi urządzeniami wejśoia-wyjśoia. Przesyłanie W 
fozmaojl odbywa się przez jeden bufor o objętośoi 41 słów dl® 
każdej staoji. Bufory te są umieszozone w pamięoi operaayd® 0 ^' 

Ze względu na koszt modułów perforatora, wszystkie perf 01 * 
tory zostały podłąozone do modułu perforatora standardowego* 

O numerze perforatora związanego z daną staoją systemu deoy*^ 
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ozęść adresowa maszynowego rozkazu iniojowania transmisji 
w Programach obsługi we jśoia-wyjśoia. W rzeozywistośoi perfo- 
r «tory praoują szeregowo, oyklioznie wyprowadzająo po jednym 
2l ^ku. Jednak z punktu widzenia użytkowników praoa perforato- 
Jest równoległa; na wszystkioh perforatoraoh jednooześnie 
Ł °że być perforowana taśma. 

Pamięć systemu MACS jest dwupoziomowa: główna — operacyjna 
Pomoonioza — bębnowa* W pamięci głównej podozas pracy syste— 
^ MACS znajduje się system operacyjny systemu MACS, transla- 
'° r Języka MARO-2 i jedno zadanie użytkownika. Z tego na zada- 
użytkownika przeznaozono pole o objętości 8K słów. 

^ pamięci pomocniczej w końcowym obszarze przechowywana 
kopia MACS (8K słów) wraz z polem operatorskim (także 8K 
s iów) w ramach oprogramowania podstawowego EMC ODRA 1204 M , na 
/t: óre pozostawiono jedną jednostkę bębna magnetycznego. 

^ pozostałej części pamięci bębnowej umieszozono 24 pola ro- 

"° C2 e do przechowywania zadań użytkowników w okresie seansu 

^acy systemu* Pole operatorskie przeznaczone jest do przeoho- 

^ w ania programów operatora, aktualnyoh informacji o zleoeniaoh 

^ytkowników (dotychczasowe koszty, hasło, stan zleoenia) i in- 

j^^maoji o pracy użytkowników (długości seansów użytkowników, 

^z a8 y reakcji*' użytkowników i systemu, ozasy transmisji itp.). 

Za leźnośoi od liczby jednostek bębna magnetycznego jaką dys- 

MACS f liczba pól roboczyoh przeznaczonych na zadania 

^ytkowników,jak też obszar przeznaozony na oprogramowanie pod¬ 
ał 

ta wowe mogą być zmieniane przez podanie odpowiednich wartości 
^ametrów przy iniojowaniu seansu pracy systemu przez operato- 
• Przez seans pracy systemu rozumiemy okres czasu od momentu 
^ r °v/adzenia systemu do pamięci operacyjnej do momentu wykona- 
** instrukoji systemowej OFF powodującej wyłączenie systemu# 


p 

r *oz oprogramowanie podstawowe rozumie się tu zestaw programów dostar¬ 
czonych przez producenta (translator języka ALGOL itp.) p umożliwiają¬ 
cych wykorzystanie maszyny poza systemem MACS. 
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3. OPIS FUNKCJONALNY 

Iniojowanie seansu pracy systemu odbywa się ze stacji nr 1 
(standardowy monitor, czytnik i perforator). System MACS może 
być wprowadzony do pamięci operacyjnej z pamięci bębnowej lub 
z taśnęr binarnej. Do wprowadzenia systemu służy speojalny pr 0 " 
gram przechowywany na taśmie binarnej. Przeprowadza on wstępu^ 
konwersację z operatorem, podczas której operator podaje dat? 
i ewentualnie nowe wartości parametrów systemu, takich jaks 
współczynniki kosztów wykorzystania procesora i stacji, licz¬ 
ba pól roboczych w pamięci pomocniczej i początkowy adres ko¬ 
pii systemu. Prooes inicjowania seansu pracy systemu jest 
szczegółowo opisany w [2]. Sygnałem rozpoczęcia seansu jest 
wyprowadzenie uwagi SYSTEM ON. Od tego momentu liczony jest 
czas globalny pracy systemu, zliczane są koszty pracy użytkow¬ 
ników, a także zbierane są informacje o zadaniach użytkowni¬ 
ków. Zakończenie seansu pracy systemu jest wynikiem wykonania 
instrukcji operatora OFF (patrz [2]), albo wykrycia błędu w 
pracy sprzętu lub programów, który uniemożliwia dalszą prac? 
systemu. W przypadku, gdy operator zakończy seans pracy syste¬ 
mu, na monitory wszystkioh stacji wyprowadzana jest uwaga 
SYSTEM OFF, a w przypadku awarii - uwaga SYSTEM ERROR n, gdzi 0 
n oznacza n um er błędu. Na zakończenie seansu wyprowadzana 
jest lista wykorzystywanych zleceń z obciążającymi je koszta¬ 
mi oraz informacje o pracy użytkowników zbierane w polu opera 
torskim. 

Jak już wspomniano MACS umożliwia tworzenie, uruohamiani 0 
i wykonywanie jednocześnie czterech programów obliczeniowych 
w języku MARO-2. Ciąg instrukcji języka MARO-2 napisany P rZ0Z 
użytkownika na monitorze stacji systemu nazywamy zadaniem, 
danie użytkownika może znajdować się w jednym z czterech sta 
nów: martwe, uśpione, zawieszone lub aktywne. Zbiór stanów za 
dania przedstawiono na iys. 2. 

wyć 

Zadanie martwe w odróżnieniu od zadania źywagfi nie może 
wykonywane, ponieważ nie ma żadnego obrazu w pamięci system^ 
Zadanie znajduje się w stanie martwym przed pierwszym wywoła¬ 
niem lub w wyniku zakońozenia seansu instrukcją CANCEL. 
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Zadanie 

martwe żywe 

/ \ 

uśpione ozynne 

/ \ 

zawieszone aktywne 
Rys. 2. Stany gadania użytkownika systemu MACS 

Zadanie uśpione zajmuje pole robocze w pamięoi pomooniozej, 

nie ma przyporządkowanej żadnej ze stacji systemu. Ostatni 
8 ®ans użytkownika zakońozył się instrukcją STOP. 

Zadanie czynne ma obraz w pamięoi pomooniozej i aktualnie 
Wydzieloną jedną ze stacji systemu. W momencie aktywowania 
^oiślej przydziału procesora) obraz zadania jest przenoszony 
^ Pamięoi głównej i poddawany przetwarzaniu. Po zakońozeniu 
Wetwarzania nowy obraz zadania jest zapisywany w pamięci po- 
Wniczej - zadanie przechodzi ze stanu "aktywne” do stanu 
2 ®wiQ SZ one”. 

Zadanie zawieszon e. Stan ten jest sygnalizowany przez system 
^Prowadzeniem na monitor znaku "X" t który stanowi dla użytków 
informaoję o zezwoleniu na pisanie kolejnego zdania. Napi¬ 
cie znaku ” t ” powoduje zakońozenie stanu zawieszenia. 

Zadanie aktywne . Zadanie znajduje się w tym stanie od momen¬ 
tu napisania przez użytkownika znaku ” ; " do momentu wyprowa¬ 
dzała przez system kolejnego znaku "X". Jest to jedyny stan, 
Wozas którego zadanie znajduje się w kolejoe do prooesora. 

Zmiany stanów zadania w ozasie seansu pracy systemu przed¬ 
stawiono sohematyoznie na rysunku 3» 

Podczas seansu pracy systemu MACS na liście zleceń, która 
Wjduje się na polu operatorskim w pamięoi pomooniozej, prze¬ 
rwane są informacje o 500 zleceniach ponumerowanych od 
0 " 499. Numer 0 jest przyporządkowany na stałe programom ope- 
^orskim, które są wywoływane w taki sam sposób jak programy 
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Rys. 3. Zmiany stanów zadania użytkownika 
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Użytkowników. Użytkownik zgłaszający się do systemu otrzymuje 
D| i operatora informaoję na jaki numer zleoenia może praoować. 

ten nie może być przydzielony wcześniej innemu użytkowni¬ 
kowi i powinien być odblokowany przez operatora za pomooą odpo¬ 
wiedniej instrukoji operatorskiej. Użytkownik, który zgłasza 
# i? nie po raz pierwszy do systemu, powinien znać przydzielony 
1111 numer zleoenia. 

W seansie praoy użytkownika można wyróżnić trzy fazy* 
identyfikaoja użytkownika, 

Pisanie dowolnyoh instrukoji w języku MARO-2 poza instruk- 
ojami STOP i CANCEL, 

zakońozenie seansu instrukoją STOP lub CANCEL. 

Każdy użytkownik systemu jest identyfikowany przez numer 
^eoenia i odpowiadająoe mu hasło wprowadzone przez użytkowni¬ 
ka w poprzednim seansie i znane wyłąoznie jemu. W oelu ochrony 
^neru. zleoenia przydzielonego danemu użytkownikowi przed ob¬ 
ciążeniem go kosztami przez innyoh, hasło użytkownika jest in- 
f °tmaoją tajną nawet dla operatora systemu. Przy pierwszym 
kłoszeniu się do systemu hasło użytkownika jest puste, to zna¬ 
czy system akoeptuje każde formalnie poprawne hasło. W przypad¬ 
ku hieznajomośoi hasła użytkownik nie jest dopuszozany do dru- 
^ e j fazy seansu. 

W fazie drugiej użytkownik może tworzyć swój program, mody¬ 
fikować i wykonywać go. Możliwe jest m.in. wyprowadzenie taśmy 
^iharnej programu w oelu późniejszego wprowadzenia go ze sta¬ 
cji wyposażonej w ozytnik. 

Instrukcje języka MARO-2, obsługa urządzeń etaoji i sposób 
c^Iiozania kosztów wykorzystania systemu zostały opisane w [i]. 

Bieżąoe saldo kosztów zleoenia system wyprowadza w fazie 
identyfikacji i w fazie zakońozenia seansu praoy użytkownika. 
*° a zty zleoenia zależą od wyposażenia staoji,- czasów praoy pro- 
c*8ora i monitora na rzeoz zleoenia oraz od ozasu przechowywa¬ 
nia uśpionego zadania w pamięol pomooniozej. 
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Na zakończenie fazy trzeciej system wyprowadza uwagę BYE, 
która oznaoza zwolnienie staoji dla następnego użytkownika. 

Jak już wspomniano programy operatorskie wywoływane są w 
ten sam sposób jak zlecenia użytkowników. Instrukcja CANCEL, 
powodująca usunięcie zlecenia jest traktowana jako niepopraw¬ 
na. W związku z tym zleoenie 0 nie przyjmuje stanu "martwe", 
może być "uśpione" lub "czynne". 

Odpowiednie instrukoje operatorskie pozwalają blokować i od¬ 
blokowywać numery poszczególnych zleceń, otrzymywać informacje 
o stanie zleoeń a nawet usuwać zlooenia uśpione w przypadku 
przepełnienia systemu tzn. w sytuaoji, gdy nie ma pola robocze¬ 
go w pamięci pomooniozej dla kolejnego użytkownika zgłaszające¬ 
go się do systemu. 


4. STRUKTURA. SYSTEMU 

Poważne ograniczenia narzucone przez sprzęt miały istotny 
wpływ zarówno na proces projektowania systemu jak też na pro¬ 
dukt, tzn. sam system. Zaważyło to szczególnie na strukturze 
systemu operacyjnego systemu MACS. 

Projekt systemu wykonany w fazie wstępnej, w której poszcze¬ 
gólne elementy programowe rozważane były głównie od strony fuD*" 
ojonalnej, uległ znaoznym zmianom w fazie weryfikacji ze wzglS" 
du na możliwośoi realizacji. Dążenie do skrajnego zminimalizo ! '’ a 
nia czasów działania i objętości zajmowanej pamięci spowodował 0 
konieczność przyjmowania najprostszyoh z punktu widzenia reali - 
zacji rozwiązań, ^rezygnowano także z jednolitośoi w budowie 
tablic systemowyoh na rzecz łatwośoi dostępu do informaoji w 
nioh zawartych. 

Programy systemu operacyjnego można podzielić na dwa zbiory* 

1. programy obsługi wejśoia-wyjśoia do komunikaoji z urządzeni® 
mi zewnętrznymi, 

2. programy nadzorcze do efektywnego wykorzystywania zasobów 
systemu. 
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&o zadań programów nadzorozyoh należy szeregowanie zadań 
j^tkowników, podział pamięoi pomooniozej pomiędzy te zadania, 
'Patrolowanie pracy urządzeń wejóoia-^jśoia i księgowanie 
sztów wykor^stania systemu. Programy nadzorcze, ich projek- 
' , ° w &nie i strukturę omawia J. Karozewski w pierwszej ozęśoi 
opraoowania. 


Omówimy tu programy obsługi wejśoia-wyjśoia ze zwróceniem 
8z <>zegóinej uwagi na ich strukturę. Programy te ze względów 
f<łll kojonalnyoh można podzielić na oztery typy: 




°t»sługa transmisji pomiędzy bębnem magnetyoznym a pamięoią 
°pera oyjną, 

obsługa transmisji pomiędzy monitorami a pamięoią operaoyj- 

'"'Prowadzanie informacji z czytnika, 

'"'5'Prowadzanie informaoji na perforator. 

2e względu na to, że w pamięci operacyjnej systemu znajduje 
* tylko jedno zadanie użytkownika, a kopie pozostałyoh w pa- 
“°i bębnowej, po zakońozeniu kwantu ozasu następuje na ogół 
J^atna zadań między pamięoią operacyjną a bębnową. Podczas 
wym iany po zainiojowaniu fizycznej transmisji procesor jest 
*° 2 ynny. W tym ozasie mogą jedynie praoowaó programy reali- 
^^ące woześniej zainicjowane transmisje między pamięoią we- 
^trzną a urządzeniami poszozególnyoh stacji. 

dogramy grupy pierwszej pracują wyłąoznie na użytek syste- 
1 ozas ich działania obniża efektywność systemu. Z tego po- 
^ podczas realizacji tych programów szczególną uwagę zwróco- 
*4 minimalizację czasu ioh wykonywania. Programy wymienione 
^^taoh 2, 5 i 4 obsługują zlecenia użytkowników. 




t J 4k już wspomniano monitory staoji 2, 3 i 4 zostały podłą- 
do kanału przesyłania słów w sposób nietypowy. Sygnały 
porwań poohodząoe od tych monitorów nie są wprowadzane do 
Nb, przez który przesyłane są informacje, lecz są przeka- 
do koordynatora kanałów do rejestru przerwań na miejsoe 
Jfen tłów z kanałów 5, 6, 7. Taka organizacja podłączenia moż- 


228 


Alina RUSZKOWSKA 


liwa była dzięki temu, że liczba różnych przerwań kanałowyoh 
(z jednego kanału) jest równa liczbie różnych przyczyn prze¬ 
rwań zgłaszanych przez moduł monitora* W przypadku innych urzą¬ 
dzeń taka równość nie zachodzi. 

To nietypowe podłączenie monitorów pozwoliło na pełniejsze 
wykorzystanie sprzętu, a jednocześnie na skrócenie programów 
obsługi. Bowiem przyczyna przerwania pochodzącego od urządze¬ 
nia, która decyduje o sposobie reakcji na przerwanie, jest 
identyfikowana przez numer zgłoszenia przerwania związany na 
stałe z określonym miejscem pamięci operacyjnej. Natomiast w 
przypadku podłączenia typowego identyfikacja przyczyny przerwa¬ 
nia następuje w wyniku analizy programowej. 

Jest to przykład przeniesienia funkcji systemu operacyjnego 
na sprzęt. Nietypowe podłączenie monitorów stanowiące niewiel¬ 
ką zmianę w konfiguracji sprzętu pełni funkcję programów anali¬ 
zujących przyczynę przerwania i deoydującyoh o wyborze progra¬ 
mu reakcji na przerwanie. 

Podczas realizacji programów grupy 2 położono szczególny na¬ 
cisk na minimalizację czasu wykonywania. Dlatego programy te są 
wykonywane pod ochroną przed przerwaniami i mają najwyższy prio" 
rytet programowy. Wykonanie ich może być wstrzymane przez pro¬ 
gramy reakoji na przerwania o wyższym priorytecie sprzętowym 
jak przerwania czasomierza, przerwania pochodzące od urządzeń 
podłączonych standardowo lub monitory stacji o wcześniejszym 
numerze, a także przez wykonywane w chwili zgłoszenia przerwa¬ 
nia fragmenty programów nadzorczych chronione przed przerwania¬ 
mi. W celu zminimalizowania czasów takich wstrzymań ochronę 
przed przerwaniami programów nadzorozych zastosowano wyłącznie 
tam, gdzie była niezbędna. W wyniku tego większość programów 
nadzorozych może być przerywana przez programy obsługi urządzeń, 
lecz nie odwrotnie. Rozwiązanie takie zostało podyktowane bar¬ 
dzo ostrym ograniczeniem łącznego czasu reakoji na wszystkie 
przerwania techniczne jakie mogą się zdarzyć w systemie. Ogra¬ 
niczenie to narzuca konstrukcja monitorów. Przy założeniu, że 
użytkownik pisze na monitorze z prędkością do 10 znaków/sekun¬ 
dę, czas jaki można zużyć na obsługę wszystkich przerwań wyno- 
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* 0.1 ms. Należy tu zaznaozyć, że monitor staoji 1, rohcdzący 
'skład standardowego zestawu sprzętu, jest podłąozony w cpo- 
typowy, podobnie jak ozytniki i moduł perforatora. 

gżenie do maksymalnego skróoenia ozasów reakcji na przorwa- 
spowodowało podjęoie decyzji o powieleniu programu obsługi 
^tltorów dla poszozególnyoh staoji. Podobnie różne 3taojo syo- 
'•b mają własne programy obsługi ozytników. Poza potrzebą opty- 
"^izaoji, na rozwiązanie takie wpłynął fakt podłąozania csyt- 
staoji 2 do KPZ, oo pooiąga za sobą różnioe w programie 
Usługi w porównaniu z czytnikiem staoji 1. 

Natomiast perforatory są obsługiwane przez jeden program 
"tyay wykonany w wersji "ozystej”, tzn. umożliwiającej nisza-, 
^ 4 ńe wykorzystywanie go na przemian przez różne staoje systo- 
Program ten nie jest chroniony przed przerwaniami. Praoujo 
różnych polaoh dla poszozególnyoh staoji i jest iniojowany 
^ 2 ez krótkie programy obronione przed przerwaniami, któro 
°^Ugują poszczególne staoje. Takie rozwiązanie pozwoliło za- 
° 8 ZQzę<izić znaozny obszar pamięoi. 

^ wnioski 

Na podstawie przytoozonego opisu systemu MACS można wyoiąg- 
^ Następujące ogólne wnioski* 

* °graniozenia narzuoone przez sprzęt mają istotny wpływ na 
strukturę systemu operacyjnego systemu lioząoego, który rea¬ 
lizowany jest dla danego sprzętu. Z jednej strony są to roz¬ 
szerzenia programowe pewnych funkoji sprzętu (np. programowe 
zapełnianie bufora monitora), z drugiej strony - dostosowa¬ 
nie struktury oprogramowania do wymagań sprzętu ogranicza¬ 
jących swobodę organizaoji współdziałania programów (wyższy 
Priorytet programów obsługi urządzeń niż programów nadzor- 
°zyoh), 

Pewne funkoje systemu operaoyjnego mogą być przejmowano przez 
sprzęt. Przykładem jest nietypowe podłąozenie monitorów w 
Maternie MACS, 
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3 . projektowanie i realizacja systemów operacyjnych wymagają 
zachowania ustalonej kolejnośoi działań: 

1 ) sformułowanie zadań projektowanego systemu operaoyjnego, 

2 ) ustalenie konfiguracji sprzętu, która byłaby zdolna rea¬ 
lizować te zadania, 

3 ) weryfikacja zadań ze względu na ograniczenia narzucone 
przez sprzęt, 

4) opracowanie struktury systemu operacyjnego, 

5 ) programowanie, uruchamianie i sporządzanie dokumentaoji* 

Nieprzestrzeganie wymienionej kolejności działań prowadzi 
do nadmiernych nakładów pracy. 

4 . wzrastająca oiągle złożoność systemów operaoyjnych wskazuje 
na potrzebę opracowania łatwych w użyciu metod formalnego 
opisu budowy, wzajemnych powiązań i zachowania poszczegól¬ 
nych elementów systemu. 
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C H0TEMA C PA3AEJIEHH0JI BPEMEHH TMA "B0I1P0C-0TBET" MACS 
^CTŁ II .OECJUMBAME BB0M-BbtB0.HA 



fi Tpyne onuotmaeTCH ^yHKunoHiipoBaHHe a CTpyKTypa cacTeMu, 
^Topaa (Jujia C03naHa BŁmacjiHTejiBHHM iieHTpOM HAU jyin 3BM 
*^4-1204 . 


MACS MOTOT MCn0JlL30BaTBCH B UeHTpaX, B KOTOptK paÓOTaiOT 
CDRA-1204 o flByMH UJM ÓOJIBUIHM KOJMHeCTBOM 3anOMHHaH)mHX 
^^poiicTB Ha MarHMTHOM óapaóaHe c ueTupBMH CTaHuaHMz, jyw 
K °TOpux OCHOBHUM OÓOpyflOBaHHeM HBJIHeTCH MOHHTOp, a BHeiHHHM 
0<3 °PynoBaHHeM nep$opaTop a c hmtub aronie e ycTpofiCTB© c nep$o- 
^POBaHHOti JieHTOll. 


npH CTaHIBLHX CHCT6MU OflHOBpeMeHHO MOryT paóOTBTB HOTblp© 
5ojI t30BaTejifl, a bo BcnoMoraTejiBHoM naMfrra mokho xpaHHTB 24 
j^°rpaMMH jyiH donee no3H»ero acnojiB30BaHafl. CncTewia ane hth— 
'“‘UupyeT n ojib 3 OBaT e jlh c noMOUfbio HOMepa 3aKa3a (cl - 499) 

‘ •totHHoro, ceKpeTHoro napojw nojiB30BaTejia. OnHOBpeMeHHO Be- 
dyxrajrrepcKntt yqeT. B 3 aKjnoHeHne ceaHca Kaanuii iiojib- 
JOfi ^Tejn, nojiynaeT HHfpopwiamno o HanacjieHua pacxoaoB, oóepe- 
^«^ddihhx ero 3aKa3. Ma oiieHKn 3$$eKTHBHOCTH bbohhtch cia- 
^TllHeCKafl OIieHKa HOKOTOpŁUC SJieMeHTOB CHCTeMbl. CTaTHCTH- 
^ c Kite naHHue onepaTop MosceT noayHaTB b sarononeraie pacaeT- 


1,0 nepnona. OnepaTop noimeH bbohhtb b cacTOMy a bhboahtb 




'°pMamno o paóoTaiomeM odopysoBamm, coctoahum chctcmh, 
*3&x no^B30BaTejieft a T.n. 

fi onacaHaa CTpyKTypH cacTeMH ocodoe BHHł/iaHHe oCpameHo na 
Hue orparomeHatt oóopynoBaHHH Ha CTpoemie cacTeMH. 
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A MULTIACCBSS CONVERSATIONAL SYSTEM MACS 
Part II. The Input-Output Organization 


Summary 


This paper presents a functional description and structure of the 
MACS system developed in Computation Centre of the PAS for ODRA 1204 co*" 
puter. 


MACS can be used in computation centres eąuipped with ODRA 1204 com- 
puters with two or morę drum memory units and four terminals with a Boni' 
tor as the basie eąuipment, and with paper tape punch and reader for i®~ 
put/output as the optional eąuipment. 


Po ur u sers may work at those terminals simultaneously, and 24 progi*®® 6 
may be stored for further use in the backing storę. The job number 
(1 to 499) and a private f secret word are to identify the user. Chargi®£ 
for time and accounting are automatically conducted at the same time. * v 
the end of conversation each of the users is obtaining the Information 
on charges for his job. In order to enable the estimation of the system 
efficiency, statistical measures for some elements of the system wer« 
introduced* Statistical data can be outputted by the operator at the e® 4 
of accounting period. 


The operator's task is also to input and output the Information on 
working hardware, system status, user s job, etc. 

In the description of systenTs structure a particular attention 1® 
paid to the influence of hardware limits on the construction of the 
system. 


© Instytut Maszyn Matematycznych 
02-078 Warszawa, ul. Krzywickiego 34 



* L GOfiYTMY, Zeszyt Specjalny, 1974,\233 -239 


68l.322.06i 

06l.3/438/"i973" 


0 PEWNEJ REALIZACJI SYSTEMU WIELODOSTĘPNEGO 
NA EMC ODRA 1204 

Janusa W. SOWIŃSKI 
Wojskowy Instytut Łączności 
Pracę złożono 10.1.1974 


^no opis realizacji modelu systemu wielo- 
^ 8t ?pnego na EMC ODRA 1204 współpracującej z 
/Rdzeniem zobrazowania graficsnego typu gra- 
System umożliwia niezależną pracę na 
a ch stanowiskach z możliwością prostej ros- 
^°wy p rzez dołączenie nowych stanowisk po- 
8° typu. System napisany został w języku 
i uruchomiony na. EMC ODRA 1204. 


Spis treści 


1 , 

1 . 

^ 1 . 

S. 


WSTĘP 

KONFIGURACJA SPRZĘTU 

FUNKCJE SYSTEMU 

STRUKTURA SYSTEMU 

Schemat strukturalny systemu 

Program nadzorczy 

ZAKOŃCZENIE 


* wstęp 

Artykuł dotyczy projektu i konstrukoji wyspecjalizowanego 
wielodostępnego dla maszyny ODRA 1204 wyposażonego w 
^itory dalekopisowe (MD) 1 urządzenia zobrazowania grafiez- 
tzw. monitory ekranowe (ME). ODRA 1204 nie była projekto - 
^4 2 myślą o wielodostępnej eksploataoJi, tym niemniej 
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istnieją w niej środki układowe, ułatwiające projektowanie 
systemu wielodostępnego. 


2. KONFIGURACJA SPRZĘTU 

Dokładną charakterystykę sprzętu zawiera dokumentacja tech¬ 
niczno-ruchowa EMC ODRA 1204 oraz opis techniczny lokalnego 
urządzenia zobrezowania graficznego LUZ. 

W omawianym systemie wykorzystano następujące urządzenia 2 

• jednostkę centralną (JC z koordynatorem kanałów i dwoma 
kanałami transmisji danych) 

• elektryczną maszynę do pisania (EMP) 

• lokalne urządzenie zobrazowania graficznego (LUZ) 

• pamięć operacyjną o pojemności 48K, przy czym bezpośrednio 
może być adresowanych 16K słów 

Natomiast bazę językową systemu stanowi język niskiego po¬ 
ziomu JAS-O , którego opis zawiera opracowanie WZE ELWRO 
"System Programowania. Maszyna cyfrowa ODRA 1204. Język Adre¬ 
sów Symbolicznych". 


3 . FUNKCJE SYSTEMU 

W omawianym systemie z maszyny korzysta się za pomocą j?" 
zyka konwersacyjnego jednolitego dla obu typów urządzeń 
zewnętrznych. 

Konwersacja odbywa się w następujący sposób. Użytkownik 
"pisze" na ekranie (lub dalekopisie) pewne wyrażenie, nadają 0 
zmiennym wartości i sygnalizując w odpowiednim momencie fakt 
zakończenia tej czynności. Odpowiodzią systemu jest wypisani 0 
wartości wprowadzonego wyrażenia dla zadanych parametrów. 

System reaguje na bieżąco na błędy użytkownika, sygnali^ 1 ^ 
jąc jednocześnie ich charakter, dzięki temu użytkownik unika 
pisania do końca wyrażenia, w którym znajduje się błąd. 
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Zes z. Spec. 

t Poni eważ dostępne były jedynie dwa urządzenia zewnętrzne 
konwersaoyjnego tzn. LUZ i EMP, realizacja systemu obej- 
j 0 jedynie te dwa urządzenia, czyniąo system dostępny w 
^aktryce dwóm użytkownikom, 

A 

• STRUKTURA SYSTEMU 

*'• Schemat strukturalny systemu 

Schemat strukturalr^r oprogramowania ilustruje rys. 1. 



Rys* 1. Schemat strukturalny oprogramowania 


Rządzenia zewnętrzne kontaktują się z programem nadzor- 
VQt (i odwrotnie) przez programy obsługi urządzeń we-wy 
^Slędniająoe specyfikę staoji. 


% 


translator języka konwersaoyjnego praoująo pod kontrolą 
°8ramu nadzorczego jest wykorzystywany jednocześnie przez 


Użytkowników systemu. W pamięci przeohowywana jest jedna 
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kopia translatora* Eałdy s użytkowników dysponuje obszarem 
roboozym, który jest wykorzystywany podesas praoy transla¬ 
tora* 


4.2. Program nadzórosy 

Program nadsorosy jest elementem oprogramowania podstawo¬ 
wego odpowiedzialnym za wykorzystanie zasobów systemu i obału- 
89 żądań użytkowników w sposób zgodny z założeniem systemu* 
tzn. w sposób wielodostępny. 

Ze względu na fakt* że realizaoja systemu wielodostępnego 
obejmuje jedynie dwa urządzenia zewnętrzne - struktura progra¬ 
mu nadzorozego jest nieskomplikowana. 

Do podstawowyoh funkoji programu nadzorozego należy i 

1) utrzymanie komunikaoji z użytkownikami przez obsługę prze¬ 
rwań kanałów transmisji oraz zabezpieozenie innyoh usług 
związany oh z konsolami użytkowników 

2) obsługa prooesu umieszozania programów użytkownika w parnię- 
oi 

3) obsługa prooesu wykonywania programu użytkownika. 

Dwa ostatnie prooesy są od siebie niezależne 1 nawzajem 
nio o sobie "nie wiedzą" - przygotowanie do wykonania progra¬ 
mu jednego użytkownika nie psa wpływu na wykonywanie programu 
drugiego użytkownika (jeżeli nie brać pod uwagę* że ozas wy¬ 
konywania wydłuża się}. 

Każdy prooes zawiera instrukoje odwołująoe się do fragment * 1 
programu nadzorozego, który inlojuje działanie kanałów. 

Ze względu na ogranlozoną (np. rozmiarem ekranu LUZ) wiel¬ 
kość formuł arytmetyoznyoh jakie mogą pisać użytkownloy, ml* 
zaohodzi potrzeba dynamioznego przydziału pamięol. 

Strukturę programu nadzorozego przedstawia rys. 2. 


Spec 
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START 

l 

przygotowanie kanałów i urządzeń 
(zezwolenie na przerwanie) 

Stan oczekiwania 
Czy przyszło przerwanie? 


TAK/ 



rozpoznanie zgłaszającego 
się urządzenia 


s NIE 



powrót do oczekiwania 


rozpoznanie przyczyny 

/ 

obsługa klawiatury obsługa sygnału 

funkcyjnej urządzenia AKCEPT 



powrót do oczekiwania 


przydzielenie translatora 


czy był błąd? 

/\ 

TAK / \ NIE 

sygnalizacja wypisanie 
błędu wyniku 



powrót do oczekiwania 


Rys. 2. Struktura programu nadzorczego 
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5 • ZAKOŃCZENIE 

Omówiona realizacja systemu umożliwia jego prostą rozbudo- 
wę przez dołąozenie kolejnyoh staoji podobnego typu (monitory 
ekranowe i dalekopisowe) dzięki wydzieleniu w strukturze sys" 
temu odpowiednich modułów obsługi urządzeń we-wy. Doświad¬ 
czenia przeprowadzone z systemem potwierdzają jego przydat¬ 
ność również w przypadku wykorzystania innyoh urządzeń ze¬ 
wnętrznych. Wzrost liozby staoji będzie się jednak wiązał 
z pewnymi niedogodnościami, np. zmianą adresowania przy prz0' 
kroczeniu 16K słów pamięoi. 

Wykonanie systemu nie kwalifikuje go do powielania i użyt¬ 
kowej eksploataoji, jednakże może on stanowić przyczynek do 
realizaoji wielodostępności na maszynaoh klasy ODRA 1204. 
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° B OJIHOH PEAJM3AHMH CHCTHffl C PA3JEJ1EHHEM BPEMEHH HA EA3E 

3BM 0DRA-1204 



HacTOHmafi Tpyn conepsoiT onHcamte peajm3anKH Mo^ejra chc- 
T eiai c pa3flejiemieM BpeMeHH Ha Óa 36 3BM ODEA-i 204 , B 3 anM 0 — 
ĄeacTByiomefi c ycTpofiCTBOM OTOdpaaeHHsi HH$opMamra Ha 3JTT 
^Pa^HHecKoro Tuna. 

CiicTeMa no3BOJiHeT npon3BOflHTB He3aBHCHMyio padoTy c UByMH 
c TaHimHrJUI C B03M0KH0CTBK) IipOCTOrO paClUHpeHHfl OÓOpyflOBaHHH 
Q yTeM uodaBJieHHH crcepenHŁoc ycTpofiCTB Toro ace Tana. CucTeMa 
a anncaHa na H3HKe jas-oh npoBepeHa Ha 3BM (DRA- 1204 . 


ak 


IMPLEMENTATION OF MULTI-ACCESS SYSTEM FOR THE ODRA 1204 COMPUTER 



H This paper oontains a desoription of tbe implementation of the 
U *ti-Access system for the ODRA 1204 Computer cooperating with the 
. a Phical display unit. The system enables independent work on tvo 
^^inals with the possibility of attachment of new terminala of simi~ 
a * r type. The system is written in JAS-0 language on the ODRA 1204 com¬ 
ber. 


^ Instytut Maszyn Matematycznych 
c '*°78 Warszawa, ul. Krzywickiego 34 
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SYSTEM OPERACYJNY EMC KAR-65 

Andrzej GECOW 
Instytut Badań Jądrowych 
Prac$ złożono 10.1.1974 


jest małą doświadczalną maszyną cyfrową 
generacji. Jej głównym zadaniem jest 
*^ ó *Praca z dwoma aparatami pomiarowymi. Opra¬ 
wę a ^ie dotyczy budowy systemu operacyjnego i 
So s ° główno j części - dyrygenta, ściśle dosto- 
?o> anych <io G P 0c y^icznych potrzeb instalacji* 
O* 2Rn0 sposób realizacji ekstrakodów typu 
? 0 N QntrantM oras podłączenia obsługi aparatów 
^^^arowych przy podziale czasu. Ponadto poka- 
- . ’ są przykłady pewnych rozszerzeń systemu 
^oriywanych w "biegu 11 . 


( 


Spis treści 

Historia i przeznaczenie maszyny 

* Właściwości sprzętu i jego konfiguracja 
’ Zadania systemu 

’ s vstem dyrygencki sdi 
’ system operacyjny otp 

* W lEŁ0D0STĘPN0ŚĆ ekstrakodów 

7 

organizacja współpracy z małym i tandemem 

’ "OPCJE w BIEGU" 

r j 

Podsumowanie 
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1. HISTORIA I PRZEZNACZENIE MASZYNY 

EMC Kar-65 jest małą doświadczalną maszyną oyfrową o logio* 
trzeoiej generaoji opartej na przerwaniach.. 

Zbudowana została w 1965 r* w Instytuoie Fizyki Doświadozal' 
nej UW. 

Głównym przeznaozeniem maszyny jest opracowywanie danyob * 
komór pęcherzykowych, polegająoe na rekonstrukoji geometryo®- 
nej i dynamicznej zderzeń oząstek elementarayoh oraz statysty*** 
nym opraoowaniu wyników. Rocznie mierzono kilkadziesiąt tysi$" 
oy zdjęć, a opraoowywanie ich na maszynie Gier zajęłoby około 
pięoiu godzin dziennie. W oelu zwiększenia wydajności aparató* 
pomiarowych podłączono je bezpośrednio do maszyny. 

Drugim głównym zajęoiem maszyny jest liozenie długo dział*", 
jąoyoh programów do badań naukowych, zawierająoych zazwyozaj 
całki wielokrotne. Programy takie dają stosunkowo bardzo krót¬ 
kie wydruki przy bardzo długim (do kilkudziesięciu godzin) 
ozasie liczenia. 

Bezpośredni dostęp do maszyny w Instytuoie pozwalał także 
na konwersaoyjną pracę z kilkoma usługowymi programami tyP u 
Edit - do poprawiania taśmy papierowej lub Arytmometr - do k*® 
wersaoyjnego obliozania wartośoi funkcji i oałek. 


2. WŁAŚCIWOŚCI SPRZĘTU I JEGO KONFIGURACJA 

Kar-65 ma 4K 26-bitowyoh słów pamięoi operaoyjnej (PAO) 
i 32 K pamięoi bębnowej. Rozkazy są jednoadresowe i mieszozą 
się w pojedynozym słowie maszyny. Konfiguraoja maszyny pok*® a 
na jest na rys. 1. 

Praoa maszyny może odbywać się w dwóoh stanach: legalno^ 0 * 
i nielegalności, nazywany oh inaczej stanami dyrygenta i użY* 
kownika* W stanie użytkownika uwzględniane są elektronie® 110 
blokady PAO, zabezpieozająoe system i inne programy przed 
zniszozeniem przez program użytkownika. W tym stanie nieo 8 ^ 
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Saln a Jest grupa rozkazów zwanyoh nielegalnymi, a używanyoh 
91 stanie dyrygenta do organizaoji we jśoia-wyjśoia. Użyć wejś- 
ota-wyjśoia można przez ekstrakody, które przenoszą akoję do 
^tygenta. 



■oni tor 15 zn /9 

czytnik główny 1000 v 500 zn/s 
perforator główny 150 zn/s 
czytnik z przekodowaniem ^dostawiany/ 

perforator z prze&uuowamem pomocniczy 75 zn /9 
czytnik pomocniczy 1000 zn/s 

perforator gromadzący opracowane wyniki 
pomiarów bezpośrednich 75 zn/a 

aparat pomiarowy Mały 
aparat pomiarowy Tandem 


Rys* 1* Konfiguracja EMC Kar-65 


Podstawową właśoiwośoią logiki trzeoiej generaoji są prze¬ 
gania, pozwalające organizować podział ozasu. Kax>-65 ma 24 
Zerwania związane m.in. ze współpraoą z aparatami pomiarowy- 
oraz gotowością kanałów zewnętrznych itp. Każde przerwanie 
z ° s tawia ślad w miejscu 0 i rozpoozyna akcję od określonego 
^sjsca pamięci, wprowadzając maszynę w stan "nie wolno prze¬ 
lać! stan ten dotyczy wszystkioh pozostałyoh przerwań i do- 
boro stan "wolno przerywać" pozwala na realizację przerwań 
bekających. Jeżeli czeka kilka przerwań, to wykonują się one 
jno wg wyznaczonego priorytetu* 

5 ‘ kADANIA SYSTEMU 

W 1970 r. rozpoczęły się praoe nad podłączeniem do maszyny 
aparatów pomiarowych o nazwach Mały i Tandem. Równooześ- 
należało podsumować doświadczenia w pracy z maszyną i sys¬ 
tem (głównie dyrygentem) oraz przygotować włączenie progra- 
obsługi tych urządzeń do systemu. 
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Speoyfiozna sytuacja jednostkowej doświadczalnej maszyny! 
oprogramowanej w assemblerze przez grupkę kilku fizyków, spo¬ 
wodowała zaostrzenie wymagań w stosunku do weryfikaoji zało¬ 
żeń i struktury systemu? z jednej f3trony konieozność dalszego 
działania oałego dotyohozasowego oprogramowania, w dużej ozęó- 
oi istniejącego tylko w postaoi taśm binarnyoh? z drugiej 
strony, ponieważ praca z tą maszyną jest w zasadzie konwersa- 
oyjna i każdy użytkownik jest równocześnie operatorem, a więo 
sposób korzystania z systemu operacyjnego nie powinien uleo 
większym zmianom. 

Mała pamięć operaoyjna przy ozęstyoh długioh ozasaoh liozo- 
nia dużyoh programów spowodowała dużą cenę miejsoa w PAO. Rów¬ 
nocześnie częste awarie bębna spowodowały, że przez długi oto. 0 
nie używano go do ważnyoh zadań. 

W tych dość nietypowych warunkaoh,przez budowę kolejno co¬ 
raz bardziej zaawansowanych systemów i ioh weiyfikaoję w nor¬ 
malnej praoy maszyny powstawał nowy system zdolny do współpi*' 
oy z urządzeniami przy podziale ozasu. 

Trzeba było pamiętać przy oddawaniu do użytku (a tym samy® 
do sprawdzenia)nowego systemu, że rezygnowanie z nowyoh włas¬ 
ności osiągniętyoh już przez ten system jest w zasadzie nie¬ 
możliwe. Powstała w ten sposób seria systemów od skdl (76° 
oktalnie miejso PAO - super krótki dyrygent) do systemu dyx5~ 
genokiego sdl z tzw. krótkim dyrygentem kd5. Górnym umownym 
ograniozeniem zajętośoi PAO przez system jest 2000 miejso 
oktalnie. 


4. SYSTEM DYRYGENCKI sdl 

System dyrygencki sdl powstał w maju 1972 r. i jest nd ^ ba ^ 
dziej rozwiniętym systemem. Obeonie już z mniejszym pośpie° he 
pracuje się nad następnym systemem. Statyozna budowa systemu 
przedstawiona jest na rys. 2. System wprowadzany jost do 
szyny z taśmy papierowej. Najpierw wczytywany jest elektron 
nie pomooniozy program o nazwie "Lokaj Anatol" (LA) znajdU- 
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8 lę na początku taśny, który następnie uruchamiany przez 
Oratora, wczytuje dalszą ozęóć taśmy na początek bębna, 

^ z ie zwykle znajduje się cały system. Skończywszy, LA przeka- 
^9 kontrolę "Lokajowi Bartkowi" (LB), który wohodzi na miejs- 
* U i po przygotowaniu obliczenia sumy kontrolnej wprowadza na 
soe, w którym się sam znajduje program - kd5» Kontrolę prze- 


»«d 


mu przez przerwanie gotowości bębna* Przerwanie to za 
9r wezym przebiegiem realizuje się odmiennie* Liozy się wtedy 
kontrolna i przestawia program przerwania gotowości bębna 
114 w łaśoiwą praoę. Można również wywołać "Lokaja Bartka" za po- 
^ ^ klucza na pulpicie. Każdy z ty oh programów melduje na moni- 
° rZe prawidłowe wykonanie się. 


PAO 


LA 

LB 


Ekstrakody i 




przerwania 




Reprezentant 

buf ox 


tf> 

MT 

LA 


n 

M 

Ekstrakody 




OTP 

ślad 



MT 



OTP 




PP 

HIT 






LW 



bufor LW 


Bęben 


LB 


kd 5 


LW 


bufor LW 


KT 


obras 

PAO 


PP 


Taśma 

inicjowania 

systemu 
LA 


LB 

kd? 

LV 


Rys* 2* Statycsna budowa sdl 


t ^ skład systemu wohodzą więc LA, LB i kd5. Rozszerzony sys- 
I ' Zawiera także programy obsługi urządzeń Mały i Tandem 
. i T) f wozytywane z taśm binamyoh przez dyrygenta kd5» 

. 4? ‘ 8 r nie zajęty przez system wykorzystuje program programis- 
? (PP). Zainiojowanie działania systemu jest odtwarzające w 
aensie, że PP może być kontynuowany, gdy awaria systemu 
1 . ’ 6 %piła w ozasie wykonywania programów systemowyoh (OTP lub 
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Krótki dyrygent (wersja 5) kd5 zawierał 

• obsługę kanałów we jśoia-wyjśoia przez ekBtrakody i przerwa¬ 
nia, 

• obsługę błędów, 

• system operacyjny OTP, 

• reprezentanta obsługi MT wykonująoego pierwsze i ostatnie 
ozynnośoi związane z obsługą przerwań Małego i Tandemu. 

Ze względu na oszozędnośoi pamięoi, biblioteka programów 
użytkowyoh przeohowywana Jest na taómaoh papierowyoh. 


5. SYSTEM OPERACYJNY OTP ' 

Do systemu operacyjnego OTP przejść można różnymi sposoba¬ 
mi: przez wykryoie pewnyoh błędów, przez specjalny ekstrakod 
końoząoy program lub naoiskająo kluoz przerwania OTP. OTP za¬ 
wiera wiele instrukoji, które można wykonywać wpisująo je z 
monitora lub wozytująo z taśmy. Są to możliwośoii ingerenoji 
w pamięć operaoyjną i bębnową, ustawiania blokad i innyoh pa¬ 
rametrów systemu lub programu, wozytywania i wypisywania taśm 
binarny oh "W” i taśm "R" oraz startowania lub kontynuaoji Pro¬ 
gramów. 

Taśmy "R", to taśmy z instrukojami OTP. Zawierają one zazwy- 
ozaj. instrukoje wozytywania taśmy binarnej, taśmę binarną P r °' 
gramu oraz instrukoję startu. Start programu lub instrukoja 
"o", przerzuoająoe wozytywanie z powrotem na monitor, końozą 
taką taśmę. Rzadko używane duże programy realizaoji instruk¬ 
cji OTP, jak np. wozytywanie i wypisywanie taśm binarnyoh bęb" 
nowych oraz Buma kontrolna bębna przeniesione zostały na bę¬ 
ben (LW) i nie zajmują stale miejsoa w PAO. Awaryjność maszy¬ 
ny i konieoznośó analizy zaistniały oh błędów w normalny oh wa- 
runkaoh sugerowały, aby nie przenosić pozostałyoh instrukoji- 
na bęben. W przypadku dłuższej awarii bębna, kd5 można wozy- 
tać z taśmy i będzie on w pełni sprawny pr^r praoaoh nie zwiś - 
zanych z bębnem, zaohowująo standardy taśm "R" i kontynuaoji 
programów. 
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OTP pozwala sięgnąć do każdego miejsca PAO lub bębna i do¬ 
linie je zmieniać. Obszar systemu jest jednak ohroniony i do- 
Piero po podaniu hasła można go oglądać i zmieniać. Dotyczy to 
Również wczytywania taśmy M R ,ł z programami obsługi Małego i Tan- 
^ Q mu na zarezerwowane pole bębna. Oohrona ta ma za zadanie 
u Qtrzeo system przed pomyłkami operatorów. 


6 * WIELODOSTĘPNOŚĆ M EKSTR/LKODĆW 

Program wykonywać można jako program użytkownika PP lub ja- 
program systemu OTP. W przypadku przerwania wykonywania 
e katrakodu wywołanego przez PP i wywołania go powtórnie przez 
dogram OTP, zostanie on wykonany na rzeoz OTP, a następnie 
^że być kontynuowany na rzecz PP. Ta własność ekstrakodów 
2w ana wielodostępnością jest jedną z głównych i najtrudniej- 
Sz ych do zrealizowania cech dyrygenta. 

Podstawową trudnością jest brak możliwości wybierania (do¬ 
gęszczania do realizacji) określonych przerwań, a równocześnie 
Wzbraniania realizacji innym. Powoduje to konieozność dopusz- 
° 2 ani a wszelkioh przerwań, gdy jedno jest oozekiwane, a więo 
* Przerwań zmieniający oh program (np. OTP lub M i T). 

Prześledzimy tę trudność na przykładzie wzk - ekstrakodu 
bytującego lub wypisującego pojedynozy znak na wskazanym 
bądzeniu (rys. 3) . Z rysunku widać, że poprzednia budowa wzk 
b pozwalała na bezpieozne przejście do innego programu za 
^ O toocą przerwania. Podstawowym problemem jest jednak zabez- 
bozenie śladu przed zuiszozeniem. Przez ślad rozumieć tu bę- 
^lemy obszar i zawartość pamięci, w którym przy wejściu do 
^Programu maszyna zapamiętuje rejestry i parametry. Pr^7 wy" 
°^°ćzeniu z tego podprogramu ślad wkładany jest z powrotem t 
C ^li rejestry i parametry są regenerowane do stanu sprzed 
* 9 3śoia do podprogramu. 

n 

^ r iyp. redakcji: Wielodostępność jest tu rozumiana jako możność ponowne¬ 
go wejścia do tego samego programu, zanim wykona się on do końca. 

* literaturze anglosaskiej używa się w tym znaczeniu słowa "reentrance". 
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ślad zostawiany przy we.jśoiu do wzk jest znikomy 1 ograni¬ 
cza się do śladu pozostawionego elektronicznie zawsze przy 
we.jśoiu do każdego skstrakodu. Pozostałe ekstrakody ozęsto wy¬ 
wołują wzk ze swojego wnętrza. Są one zazwyozaj bardziej skom¬ 
plikowane i potrzebują kilku (nie wszystkich) rejestrów. Po¬ 
nieważ jeden program może być w jednym ozasle tylko w jednym 
ekstrakodzie, wystarozy jeden wspólny podprogram pozostawiania 
śladu i reganeraoji rejestrów. 



Rys. 3. Stara i nowa organizacja wzk 

Zawsze przy przejściu do OTP z PP ślad ten przenoszony 
na inny obszar. Ślad pozostawiony elektronioznie oraz komór* 
robocze ekstrakodów porozrzucane są po pamięci i nie stano 
zwartego bloku. Te miejsca także.zostają przeniesione. Tera* 
dopiero OTP może korzystać z ekstrakodów. Przed powyższymi 
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, na samym poozątku OTF zapamiętuje stan rejestrów, 
ten sposób powstaje ślad OTP, w którym znajduje się zawar- 
rejestrów i stan dyrygenta właśoiwego (tzn. wlelodostęp- 
a ^°h ekstrakodów). 

Umiejscowienie śladu OTP za kd5 w PAO, a tuż przed PP, poz- 
na przeniesienie śladu wraz z PP w jednym bloku na taśmę 
^tarną lub bęben, i nie narażająo ohronionego obszaru syste- 
Pozwala wprowadzić z powrotem na to samo miejsce. W mię- 
^ *7 czasie można zniszczyć ślad w PAO, tzn. np. liozyć inne 
igramy. Powyższa organizaoja umożliwia przerwanie i wznowie- 
** w dowolnym miejscu każdego programu. 



I 


ORGANIZACJA WSPÓŁPRAC! Z MAŁYM I TANDEMEM 


Siad przerwań M i T jest umiejsoowiony między śladem OTP 
^ Programem OTP, co ułatwia zaohowanie go podozas ponownego 
^cjowania systemu, ślad MT zawiera dodatkowo informaoje o 
^“Zerwaniach operatorskich, takich np. jak OTP. W ozasie dzia¬ 
nia programu obsługi MT, wszystkie przerwania operatorskie, 


t>o 


których miałby być wykonywany inny program np. 


OTP, są 
przez 


borowane. Organizację MT opraoowaną i zrealizowaną 
Vli 'ka Szożakowskiego przedstawia iys. 4. 

Ua bębnie istnieją dwa niezależne, równoprawne i różne pro- 
obsługi M i T. Różne jest samo wnętrze programów obsłu- 
natomiast przedstawiona na iys. 4 organizaoja zewnętrzna 
^ 8 t identyozna. Gdy przerwanie poohodzące od jednego aparatu 
^ 8 tąpi podozas obsługi drugiego, to zostaje ono zapamiętane, 
^aiej kontynuowany jest przerwany program, a po jego zakoń- 
* 6 hi u przerwanie to jest symulowane. 

Przebieg współpraoy obydwu urządzeń z systemem w ozasie 
tt>lta 2uje schemat na rys. 5* 


Rełna infoimaoja o stanie programów obsługi M i T znajduje 
wraz z nimi na bębnie i jest aktualizowana dopiero po po¬ 
iłbym opraoowaniu poroji danych. Pozwala to na ponowne wpro- 
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kontynuacja XF v 


Bys. Schemat współpracy systemu z programami obsługi aparatów 
wych 
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wadzenie i inicjowanie dyrygenta w każdej oliwili, bez straty 
Uzyskanych pomiarów* Można także na nowo wprowadzić programy 
MT i zainiojować je nie niszoząc PP,' a jedynie przerywając go 
®a ohwilę. 



M 0 IP D_f, 

Po t KOI? 


0 

n 



udostępnieni* ekstrakodów /i PAO dla KZ/ 

] regensraoja ekstrakodów /i PAO dla MT/ 
opf> ślady 

Rys* 5* Przykładowe przebiegi czasowe wymiany programów 
"OPCJE W BIEGU" * 

Pomiary na aparataoh MIT wykonywane są bez przerwy, a 
*ięo nigdy nie ma takiego ozasu maszyny, w którym można by by- 
io bez szkody dla pomiarów robić doświadozenia z nowymi rozwią¬ 
zaniami dyrygenta. Wstrzymywanie pomiarów jest niepożądane. 
Równym problemem, który ma być rozwiązany w następnym syste¬ 
mie jest buforowanie wejśoia-wyjśoia. W doówiadozeniaoh trzeba 
Więo manipulować programami reakoji na przerwania. 


Przyp. redakcji] Pojęcia "opcja" oznacza tu pewną dodatkową funkcję 
systemu operacyjnego uzyskiwaną przez jego rozszerzenie. "Opcja w bie¬ 
gu" oznacza rozszerzanie systemu w czasie jego pracy. 
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W tej sytuaoji przyjęta została metoda "opcji w biegu" P°~ 
legająca na reorganizacji systemu przez interpretację taśmy 
"R". Dyrygent zmieniany jest podozas własnej pracy i często 
się zdarza, że końcowe instrukoje OTP mają już nową treść. 
Równocześnie obsługa M i I działa bez zakłóceń. Opisana w roZ' 
dziale poprzednim organizacja MT - dyrygent pozwala w razie 
pomyłki na powrót do prawidłowej sytuacji. Powyższa metoda 
"opcji w biegu" należy do trudnyoh zagadnień "samoprzeorgani" 
zowującyoh się" programów. Tą metodą opracowano: program W i 
V, trójprooesowy program przetwarza taśmy Tbl oraz użytkową 
upoję systemową mb2 - Monitor Buffer V-2. 

Sohemat programu W przedstawia rys. 6. Sohemat programu » 
jest podobny. Wspólnym uzupełnieniem jest "Wakrzesioiel" doda" 
ny do współpracy z MT. Są to procedury podmieniające ekstra- 
kod wzk (rys. 3) w programaoh wypisywania i wozytywania taś® 
binarnych. Procedury powyższe pozwalają na wykorzystanie P rZ0Z 
inny program (IP) ozasu oozekiwania na gotowość urządzenia. 
Jednak gdy działa program obsługi MT, przerwanie z gotowego 
urządzenia nie może być obsłużone, gdyż obszar, którego doty' 
czy obraz taśmy binarnej w PAO przeniesiony został na bęben* 

O nie obsłużonyoh przerwaniach "przypomina sobie" periodyozni 0 
program "Wskrzesiciel" (wykorzystująo przerwania zegarowe)• 

W opoji Tbl rejestry zostały przypisane do prooesów bąd^ P° 
dzielone między nie — według określonyoh reguł• Pozwoliło 
uniknąć ozasoohłonnego ich zaohowywania i regeneraoji. Opoj a 
ta składa się z następująoyoh trzeoh prooesów (pięoiu elem 0D 
tów) i 

1) wozytania znaku z taśmy do bufora wejśoiowego, 

2) a) wyjęcia znaku z bufora wejśoiowego, 

b) opracowania go przez program, 

c) wpisania wynikowego tekstu do bufora wyjśoiowego, 

3) wypisania znaku z bufora wyjśoiowego. 

Ponieważ programy prooesów 115 działają w stanie ,ł ni f 
no przerywać" f przerwanie OTP może nastąpić jedynie w oza 
realizacji procesu 2. 
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Przerwanie gotowości 


perforatora 


|porf. rotów") 


powrót do 


f cny W 
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Przerwanego Vf 
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regon,rej. IP 
ńfeW 


IP 


akcja perforatora! 


procedura zastępująca 
wzk dla opcji W 


przerwania 



gotowości c*vtnJVn 

Rys. 6. Schemat procedury W i programu '•Wskrzesiciel" 


Zastosowana tu metoda pozwala znacznie przyśpieszyć reali- 
^Qję programów, które mogą podporządkować się narzuconym ogra- 
^czoniom, a limitowane są czasem wczytania lub wypisania taś- 
Programy procesów 1 i 3 oraz bufory znajdują się na obsza- 
PAO nie przenoszonym przez MT. Mogą one działać także pod¬ 
paś praoy programów obsługi M i T, gdyż wykorzystują tylko je- 
rejestr, którego regeneracja nie zabiera zbyt dużo czasu. 
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Dwie omówione powyżej opoje to doświadozenia przeprowadzone 
w oelu dobrania odpowiedniej metody buforowania z podziałem 
ozasu w przyszłym systemie. 

Użytkową opcją do systemu sdl Jest mb2. Pozwala ona na bu- 
forowanie monitora, a więo na pisanie i czytanie podozas pra- 
oy MT. 

Obsługa aparatów pomiarowych zajmuje ponad połowę ozasu P ra " 
oy maszyny, a ozas każdego wywołania programu obsługi M lub ® 
wynosi około 3 s. Bez opoji mb2 podozas praoy MT monitor by* 
zablokowany* Przy zazwyczaj konwersaoyjnej pracy z maBzyną bar' 
dzo ozęste 3-sekundowe ozasy oczekiwania na wpisanie jedneg 0 
znaku okazały się zbyt męczące. Opoja mb2 zbudowana jest podob¬ 
nie jak opoja Tbl. Dochodzi tu jednak kilka nowyoh warunków 
współpracy wyznaozonyoh przez techniozne właściwości monitora* 
Program, który w praktyce wraz z buforami zajął tylko 200 
miejso oktalnie PAO, osiągnął tak wielkie skomplikowanie wBpś* 
zależności, że wykazanie jego poprawności wydawało się nieoBiS 
galne. 

9. PODSUMOWANIE 

Wraz z opoją mb2 i doświadczalną opcją V/ i V system sdl * 8 
wiera następujące współpracujące procesy: 

1) PP - program użytkownika, 

2) OTP - system operaoyjny, 

J) T - obsługa Tandemu (element MT), 

4) M - obsługa Małego (element MT), 

5) pka - napełnianie bufora wejśoiowego w mb2, 

6) pkb - wypisywanie z bufora wyjściowego w mb2, 

7) w - wypisywanie taśmy binarnej, 

8) V - wczytywanie taśmy binarnej, 

9) “'Wskrzesiciel* - pomocniczy program dla opcji W i V. 

Korzystając ze standardowych taśm "R" zawierająoyoh zeSP& 
instrukcji przeniesienia i kontynuaoji programów, można P oV 
szyć dowolnie liozbę PP . 

Jedynie wielkość PAO potrzebna dla MT podozas wykonywań 
obsługi Małego i Tandemu uniemożliwia równoczesne uruchomi 8 
dwóch dodatkowych procesów opoji Tbl. 
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ohepauhohhah chctma sbm kar -65 



Kar-65 - 3T0 3KCn6pHM6HTajIBH&JI BUTOCJEITOJIBHaH MaHECHE 
(3BM) TpeTtero noKOjieHHH. B ochobhom 0Ha npeRHa 3 HageHa r am; 
®0BM8CTHOfi paóOTH C RByMfl H3M8pHT8 gŁHMMH yCTaHOBKaMH. 


B HacToamefl pa3padoTKe odcyawaeTCg CTpoeime onepamioHHoft 
c 0ct8mu h rjiaBHaa ee aacTB - nporpaMMa-RHpiocep, tocho co- 
^JiacoBaHHHe co cnems$HHecKHMH TpedoBamiHMH 3BM. IIpeRCTaBJW- 
cnocod ocymacTBaernw aKCTpaKOROB Tana "reentrant" , a 
T &Kxe motor noRKraoaeHHfl odcaymBanag h3Mopmtojibhhx ycTaHO- 
6 °k npa pacnpeRejioHHH bpomohh. KpoMe Toro, npuBORarcH npa- 
^SpŁI ROdaBOgHHX BO3MOSHOC T 6 paCfflHpeHHH CHCT8MŁI C pa3R8JI8- 
KlIe M BpeM8HH, npOH3BORHMOrO BO BpeMfl padOTH CHCT8MH. 


1118 KAR-65 OPERATING SYSTEM 



^ Kar-65 is a smali axparlmental 3rd generation Computer* Its maln task 
^ °n-line cooperatlon with two measurement devices. Dlscussion concerns 
. Q operating system and supervlsor construction which suit speclfic 
^•taliation requirements« Implementation of reentrant extracodes and of 
^tware interface between the system and the devicss servlced on-line 
shown. Some ex*mples of time-sharing system optlons are glven. 
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TELSPIS - ST8TEM GROMADZENIA 

I WYSZUKIWANIA INFORMACJI 

O ABONENTACH TELEFONICZNYCH 

Wiesław BABCZBNKO 

Okręgowa laboratorium 
Poczty i Telekomunikacji 

Praoę słożono 10.1.1974 


^ opracowaniu przedztawiono system gromadze¬ 
nia i wyszukiwania informacji "TELSPIS" wy¬ 
konywany przez Ośrodek Informatyki Teohnlos- 
n «j i Przetwarzania Danych w 0ŁP1T w Warsza¬ 
wę w ramach systemu "TELSIT". Omówiono za¬ 
gadnienie modularnóści systemu. Przedsta¬ 
wiono koncepcję pamięci hierarchicznej i za¬ 
sądzania danymi w takiej pamięci. 


Spis treści 

CHARAKTERYSTYKA SYSTEMU TELSPIS 
MODULARNOŚĆ SYSTEMU 
SYSTEM ZARZ4DZANIA DANYMI 
Realizacja poziomi* pamięci hierarchicznej 
Zarządzanie zbiorami danych 
ZAKOŃCZENIE 

1. CHARAKTERYSTYKA SYSTEMU TELSPIS 

TELSPIS wohodzi w skład systemu TELSIT, któiy jest syste¬ 
mem automatyzującym podstawowe usługi telekomunikaoyjne dla 
ludności i składa się z następujących podsystemów! TELSAfiT, 
^LLOK, TELKUR, TELSEEWIS, TELSPIS. 


1. 

3. 

3.1. 

3-a. 
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TELSART jest systemem rozliozeń tolefonioznyoh, tzn. świad" 
ozy usługi w zakresie rejestraoji liozby rozmów dla poszoze- 
gólnyoh abonentów, wystawiania raohunków telefonloznyoh i 
konywania różnego rodzaju zestawień i statystyk. 

TELLOK jest systemem informaoji lokalnej o dyżuraoh aptek 
i szpitali, repertuarze kin i teatrów, muzeaoh, wystawaoh, 
itp. 

TELKUR śwladozy usługi w zakresie biura zleoeń, tzn. bud*l 
i przypomina o różnyoh terminowyoh sprawaoh. 

TELSERWIS świadozy usługi w zakresie biura napraw, a wl9° 
prowadzi ewidenoję uszkodzeń i napraw oraz związanyoh z ni®* 
rozliozeń. 

TELSPIS jest systemem gromadzenia i wyszukiwania informa" 
oji realizująoym funkoje biura numerów, tzn. gromadzi dane 0 
abonentaoh telefonioznyoh, aktualizuje posiadaną informaoji* 
udziela na żądanie informaoji o abonentaoh, zadaje różnego 
rodzaju spisy i katalogi. 

System TELSPIS oharakteryzuje się następująoymi oeohami* 

• możliwośoiąprzeohowywania 200 tys. «$• 1 min dokumentów * r ^ 
dłowyoh, 

ę możliwośoią przyjmowania 300 -f- 600 dokumentów dziennie* 
kumenty te na ogół dotyozą zmian w istniejąoyoh już zap*' 
saoh, 

• liozbą usługi 30 4-50 tys. dziennie, 

• wielodostępnością i jednoozesna obsługa 16 rr 32 staoji n 
zależnyoh użytkowników, 

• średnim ozasem reakojii 5 4*15 a» 

• modularną konstrukoją umożliwiająoą modyfikaoję i rozbu 
wę systemu. 
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2. MODULARNOSć SISTEMU 

Aby poznać i opanować dowolny skomplikowany prooes stara- 

się go uprościć wyróżniając w nim moduły (bloki funkojo- 
balne) realizująoe prostsze prooesy składowe i określająo po¬ 
wiązania między nimi. Takie postępowanie można kontynuować 
^zieląo duże moduły na mniejsze. 

Fostępująo tak pr^ projektowaniu systemów oprogramowania 
°trzymamy zbiór modułów, tzn. funkojonalnie wyodrębnionych 
sekwencji rozkazów, które kontaktują się ze sobą w standardo¬ 
wy sposób. 

Takie podejśoie zastosowano przy projektowaniu systemu 
^ELSPIS. Składa się on z modułów podsystemów (rys. 1), z któ- 
tyoh każdy ma także budowę modularną. Przedstawienie systemu 
w postaci połąozonyoh bloków funkcjonalny oh sprawia, że jest 
°n przejrzysty, oo pozwala szybciej wyohwyoić błędy i niepra¬ 
widłowości. 


SYSTEM TELSPIS 



Rys. 1. Struktura ayataau TELSPIS 

Porównanie struktur podsystemów umożliwiło wykrycie podo¬ 
bieństw, szozególnie w modułaoh przetwarzająoyoh zbiory da- 
ty oh, uogólnienie funkcji i unifikaoje modułów. Zmniejszenie 
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liczby różiyoh modułów przyo^jmiło się do obniżenia nakładu 
praoy przy realizaoji systemu, a dokumentaoja zyskała na przed' 
rzystośoi. 

Dołąozająo nowe moduły można sukoesywnie wdrażać system 
przeohodząo od modelu do systemu pełnego* Stosunkowo łatwa 
wymierna modułów stwarza możliwość praktyoznej ooeny pr^rdat- 
nośoi różny oh algorytmów oraz dostosowania struktury systemu 
do zmieniająoyoh się wymagań użytkownika. 

Uniwersalność i nadmierna liozba modułów wydłużają ozas 
reakoji systemu, oo może wywoływać opory realizatorów. Jed¬ 
nak możliwość przyspieszenia realizaoji systemu i zwiększenia 
jego niezawodnośoi na drodze wykorzystania już istniejących 
i sprawdzony oh modułów świadosy na kor^rść modulamośoi, 
zwłaszoza przy zwiększającym się niedoborze odpowiedniej ka¬ 
dry praoowników. 


3* SYSTEM ZARZ4DZANIA DANYMI 


Zróżnioowanie pod względem intensywnośoi wykorzystywania 
przetwarzanej informaoji skłania do zastosowania pamięoi hi 6 " 
rarchioznej, składająoej się z poziomów o różnym ozasie dofl" 
tępu. Zarządzanie zbiorami daiyoh oraz pamięć hierarohiozna 
tworzą system zarządzania danymi (rys. 2). Częśoiej wykor^ 0 ' 
tywana informaoja jest związana z poziomami o krótszym oz‘i®* a 
dostępu, a wyszukiwanie informaoji zaozyna się od poziomów 
łatwiej dostępnyoh i przeohodzi do trudniej dostępnyoh, 6^ 
wynik wyszukiwania był niepomyślny. 

r 



Rye. 


Pamięć hiararchicena 
2. Syatam zarządzania danymi 
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Takie rozwiązanie pozwala osiągnąć odpowiednie paranie try 
czasowe przy umiarkowanym wzroóoie kosztów. 

W systemie TELSPIS stosowane są pamięoi masowe o dostępie 
sekwenoyjnym (taśmy magnetyczne) i bezpośrednim (dyski magne¬ 
tyczne wymienne i stałe)• Najmniejszą jednostką informacji, 
którą można adresować, jest blok, który ma jednakową długość 
we wszystkich typaoh pamięoi. 

W pamięoi hierarchicznej wyróżniono oztery poziomy (pamięć 
operaoyjna, dyski stałe, dyski wymienne, taśma magnetyozna), 
Przy czym nie wszystkie poziomy muszą istnieć. 

System zarządzania danymi wykorzystuje! program Exeoutive, 
Program realizaoji poziomów PfiP oraz program operowania zbio¬ 
rami POZ (iys. J), i daje użytkownikowi dwie możliwośoit ope¬ 
rowanie na spójny oh zbioraoh danyoh niezależnie od ioh struk¬ 
tury i położenia oraz operowanie bezpośrednio na dany oh 
umieszczonych w poszczególnych poziomach pamięoi (rys. 4) • 

W obu przypadkach możliwy jest bezpośredni i sekwenoyjny dos¬ 
tęp do informacji. 

Program realizaoji poziomów PRP umożliwia traktowanie po¬ 
ziomów pamięoi jako obszarów spójny oh. 

Program operowania zbiorami POZ sprawia, że zbiory stają 
&ię spójne. 

Program Exeoutive (poza innymi funkcjami) zarządza zbiorem 
fizycznych urządzeń we-wy, ozyni możliwymi równoległe przesła¬ 
nia do różnyoh kanałów, przy czym liozba kolejek przesłań 
jest taka ssana jak liozba kanałów. 


3.1. Realizacja poziomów pamięoi hierarchicznej 

Poziom pamięoi jest spójnym obszarem bloków odpowiadają- 
oyoh fizyoznym blokom w pamięoiaoh masowyoh. Innymi słowy 
jest to zbiór bloków w pamięoi operacyjnej lub kanałów i sta¬ 
cji pamięci masowyoh. Związek między fizycznymi jednostkami 
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Hys, 3. Poglądowy schemat organizacji systemu zarządzania danymi 

TDZ - tablica definicji zbiorów, TDP - tablica definicji P 02 * 0 
mów pamięci 
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Rys. 4. Poziomy realizacji przesłań 

WE1i WE2 - wejdcia dla programów użytkowych 
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pamlęoi a poziomami pamlęoi hierarohioaneJ określa tablioa 
TDP definioji poziomów, przyporządkowująca każdemu poziomo¬ 
wi Jegp definioję zawierającą m.in. liozbę kolejny oh kanałów, 
liozbę staoji w kanale, parametry staoji pamlęoi masowej, typ 
Pamlęoi i algorytm numerowania bloków-. Bloki informacji w fi- 
zyoznyoh pamięoiaoh są numerowane zgodnie z przyjętym algoryt¬ 
mem, przyporządkowującym każdemu blokowi numer w poziomie* Przy¬ 
jęto dwa algorytmy numerowania. Jeden z nioh określony Jest 
Przez wyrażeniet 

NBP = NB + b . (NP + p (NC + o. (NS + NK . s») 

gdziet 

NBP — nr bloku w poziomie pamlęoi, 

NB - nr bloku na śoieżoe, 

NP - nr śoieżki w oylindrze, 

NC - nr cylindra w staoji, 

NS - nr staoji w kanale, 

NK - nr kanału w zbiorze kanałów poziomu, 
b - liozba bloków w śoieżoe, 
p - liozba śoieżek w cylindrze, 
o - liczba cylindrów w staoji, 
s - liozba staoji w kanale. 

Adres informaoji zawiera m.in. nr poziomu pamlęoi i numer 
bloku w poziomie. Numer poziomu określa za pośredniotwem TDP 
definioję poziomu. Wyznaozenie adresu rzeo^ywistego bloku do¬ 
konuje się na podstawie numeru bloku w poziomie, algorytmu nu¬ 
merowania i definioji poziomu. 

Program realizacji poziomu przekształoająo parametry prze¬ 
słania na parametry rzeozywiste zastępuje przesłanie między 
Programem użytkowym a poziomem pamlęoi hierarohiozneJ sekwen¬ 
cją przesłań między programem a fizyoznymi pamięoiaml, a do 
ioh realizaoji wykorzystuje rozkazy we-wy programu Exeoutive. 
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3*2. Zarządzanie zbiorami danyoh 

Zbiór jest ciągiem rekordów informacji zapisanym w spójnym 
obszarze bloków odpowiadających blokom w poziomach pamięci. 
Określa go numer zbioru i długość, wyrażona liczbą zajmowanych 
bloków. 


Zbiór dzieli się na podzbiory o numerach 0 -f* 3 według in¬ 
tensywności wykorzystywania informacji. Nie wszystkie podzbio¬ 
ry muszą istnieć. Numer podzbioru określa jednocześnie numer 
poziomu pamięci, na którym jest umieszczany. Jeżeli sekwencja 
rekordów w zbiorze jest dzielona między poziomy pamięci, a 
więc występuje w różnych podzbiorach, to wszystkie jej części 
są powiązane w łańcuch według rosnących ozasów dostępu (rys.5>)‘ 




Rys. 5. Przykładowa struktura zbioru; faktyczna i widziana przez użyt¬ 
kownika 

Wszystkie istniejące w systemie zbiory są rejestrowane 
tablicy definicji zbiorów (TDZ), która określa wielkość i 
strukturę zbioru oraz podaje przyporządkowanie między adresem 
informacji w zbiorze a numerem poziomu i adresem informacji 
w poziomie. 

Adres rekordu informacji zawiera m.in. numer zbioru, nr 
bloku w zbiorze i adres początku rekordu w bloku. Numer zbio¬ 
ru wyznaoza położenie jego definicji TDZ. Nr bloku i adres 
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początku rekordu informacji w bloku pozwalają wyznaczyć numer 
Poziomu i adres informacji w poziomie* Program POZ przekształ¬ 
cając parametry przesłania według powyższego algorytmu na pa- 
Fometiy dotyczące poziomów zastępuje przesłanie między progra¬ 
mom a zbiorem sekwencją przesłań między programem a poziomami. 

Przedstawiona powyżej koncepcja pamięci hierarchicznej dla 
Przetwarzanych w systemie danych jest realizowana programowo 
i nie stawia speojalnych wymagań odnośnie sprzętu. Optymalizu¬ 
je ponadto system ze względu na koszty i czas reakcji* Ma to 
istotne znaczenie ze względu na występujący w wyniku zwiększa¬ 
jących się potrzeb wzrost ilości przetwarzanej informacji* 


ZAKOŃCZENIE 

Modularne podejście do projektowania oraz niezależna od 
Sprzętu koncepcja pamięci hierarchicznej mogą znaleźć zasto¬ 
sowanie także w innych systemach informatycznych* 
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TE1SPIS - CHCTEMA HAKAIIMBAHM M DOHCKA MH^OBIAUHW 0 T KJ1E - 
®OHHUX ABOHEHTAX 


Pe3K)Me 


B HacToaueJi pa 3 paÓ 0 TKe oriMCUBaeTCH cucreMa uaKan juiłb aiiwn 
u noncKa HH^łopMapitH" telspis ", pa3paóaTUBaeMafl Uohtpom tox- 
hhhcckoK MH^opMaujm h odpaóOTKH b OJITluT b BapmaBe, b 

paMKax CUCT6MU " TEL3IT ". OócyamaeTca npo&neMa moayjibhocth 
CHOTeMu. Il3JiaraeTCH KOHueimaa nepapxHaecKOii nawara u ynpaB- 
Jieifflfl flaHHHMH B 3TOlł HaMHTH. 


TELSPIS - A STORAGE AND Rfc*RIEVAL SYSTEM FOR INFORMATION ABOIJT TEIE- 
PHONE SUBSCRIBERS 


Summary 


Thia raport shows a storage arnl retrieval system called "TKLSPIS 11 
realized by the Centra of Teohnical Informatics and Data Processing * n 
OLPiT, Warsaw, as a part of the "TELSIT” system, 

Modularity of the system is discussed. 

The idea of the hierarohioal storage and data management in such a 
storage is shown. 


© Instytut Maszyn Matematycznych 
02-078 Warszawa, ul. Krzywickiego 3^ 
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SYSTEM INFORMOWANIA KIEROWNICTWA RESORTU 

ElibietiTl. WYSMULEK 
Instytut Energetyki 
Pracf złożono 10.1.1974 


Omówiono wielodostępny system konwersacyjny 
KONWERS, pełniący zadanie zautomatyzowanej 
służby informacyjnej dla kierownictwa resor¬ 
tu, umożliwiający wizualną prezentację infor¬ 
macji ułatwiających podjęcie optymalnej decy¬ 
zji. Podano opis ogólny systemu, omówiono 
sprzęt, zasady współpracy, konserwację i za¬ 
sady pracy użytkownika z systemem KONVERS. 
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Teksty standardowe i diagnostyka błędów w konwersacji 

użytkownika z systemem KONWERS 
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Elżbieta I. WYSMUŁEK 


1. OGÓLNY OPIS SYSTEMU KONWERS 
1.1. Wstęp 

System informowania kierowniotwa resortu KONWERS jest wie¬ 
lodostępnym systemem konwersaoyjnym. Istotą systemu jest to, 
że w zależności od przebiegu przetwarzania informaoji przez 
system liczący użytkownik może zmieniać program swego postę¬ 
powania. Instrukoje dla systemu KONWERS podawane są przez 
użytkownika bezpośrednio z konsoli, a wykonywane przez system 
w sposób interpretacyjny. W oelu uruchomienia systemu użytkow¬ 
nik podaje identyfikującą go informaoję (p. 2.2). Z chwilą, 
gdy KONWERS nada sygnał gotowośoi do współpracy, użytkownik 
rozpoczyna podawanie kolejnyoh instrukcji. Znak zakończenia 
pisania instrukcji spowoduje, że system rozpooznie jej wyko¬ 
nywanie. Przewiduje się, że z systemu KONWERS, w oiągu ustal 0 " 
nego okresu łączności, będzie mogło korzystać kilka komórek 
organizacyjnych, z których każda będzie miała przydzieloną 
konsolę. Nad współpraoą komórek organizacyjnych z systemem 
KONWERS ozuwa użytkownik, posiadający speojalne uprawnieniai 
zwany dalej menażerem. 


1.2. Systemowy zbiór informaoji 

Używane w opisie systemu KONWERS pojęcie informacji pień' ll,ot 
nej rozumiemy jako informaoję wprowadzone do pamięoi systim 0, 
Informaoję te mogą poohodzić bezpośrednio z pierwszego żródl fl 
powstawania informaoji jak również mogą przejść pracodhłonny 
i wieloszozeblowy prooes przetwarzania, przy ozym, zarówno P 1 '' 
oedura przetwarzania jak i środki teohniozne użyte do prze t,fffl 
rzania nie są istotne. W przypadku współdziałania z system®® 
KONWERS systemów API - informaoję wtórne w tych systemaoh bę 1 ^^ 
dla KONWERS-u informaojami pierwotnymi. 

System KONWERS będzie przekazywał użytkownikowi informaod 6 
w takiej postaoi, w jakiej zostały one wprowadzone do pamiś 0 * 
systemu. W związku z tym informaoję te muszą być przetwarzań® 
w innyoh systemaoh. Przewiduje się, że w pierwszym okresie 
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funkcjonowania systemu KONWERS przetwarzanie informaoji i 
przygotowywanie konkretnych pytań odbywać się będzie nosa ma¬ 
szyną cyfrową. Długość tego okresu zależeć będzie od urucho¬ 
mienia modułowyoh systemów API i budowy resortowego banku in¬ 
formacji. Informacje pierwotne dla systemu KONWERS stanowią 
odpowiedzi na pewną liczbę pytań. Liozba pytań może być zmie¬ 
niana w zależnośoi od potrzeb użytkowników i pojemności pa¬ 
mięci pomocniczej maszyny cyfrowej. Pytania otrzymują kolejne 
numery od 1 do 999 (maksymalna liczba pytań w obecnej konfi¬ 
guracji systemu). Ustalono, że każda odpowiedź na pytanie 
składać się będzie z 4 wariantów, każdy wariant z 3 poroji, 
każda porcja z 1040 znaków (maksymalnie). Zakładamy, że pierw¬ 
sza porcja 3 wariantu (siódma kolejna) zawiera najbardziej 
aktualną odpowiedź na pytanie. 

Całkowita lub ozęśolowa aktualizaoja danych odbywa się w 
czasie seansów menażera (p. 2.3) dwoma sposobami: przez wozy— 
tywanie informaoji z czytnika kart lub z monitora ekranowego, 
albo przez odczytywanie ioh z pamięoi pomooniozej, gdzie zo¬ 
stały umieszczone za pomooą modułowych systemów API. 


1.3. Konflguraoja sprzętu lloząoego dla systemu KONWERS 

Przewidujemy zainstalowanie w gabinetaoh członków kierow¬ 
nictwa resortu monitorów ekranowyoh z klawiaturą. Monitory 
te będą połączone z maszyną cyfrową CDC 3170 wyposażoną wi 

a) pamięć operacyjną o standardowej wielkości (64 K słów 
24-bitowyoh, ozas dostępu l,??^®)* 

b) pamięć pomooniozą w postacit 

b') dysków (o pojemności 2 M słów każdy, średni ozas do- 

stępu 165 ms) 

b") taśm magnetyoznyoh (o pojemnośoi 8 M słów każda) 

o) ozytnik kart perforowany oh (1200 kart/min) 
d) drukarkę wierszową (1500 linii/min) 
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Wymagana pojemność pamięoi pomooniozej zależeć będzie od 
objętości zbioru dany oh, a zatem od potrzeb użytkowników* 
Przewiduje się, że maszyna wraz z drukarką i ozytnikiem ob¬ 
sługiwana będzie przez speojalnie przeszkolony personel 
ośrodka obliczeniowego, natomiast ekrany będą do bezpośred¬ 
niej dyspozycji ozłonków kierownictwa resortu. Do jednego z 
ekranów musi mieć dostęp menażer systemu KONWERS. Poozątkowo 
mają być zainstalowane trzy monitory ekranowe. KONWERS dopusz- 
oza obecnie 10 stanowisk monitorowych, ale liczbę tę można 
zwiększyć. 

Ze względu na przeznaczenie systemu KONWERS i odpowiedział" 
ność za udzielane przezeń informaoje wszystkie dialogi prze - 
prowadzane z systemem są rejestrowane na taśmie magnetycznej* 
Na speojalne żądanie otrzymuje się z zapisu wyoiąg obejmują¬ 
cy dialogi przeprowadzone przez określonego użytkownika w 
określonym dniu. Po upływie ustalonego ozasu (2-J doby) zare¬ 
jestrowane dialogi mogą uleo zataroiu, jeśli nikt nie zgłosił 
zastrzeżeń, albo jeśli nikt nie prosił o kopie. 


2. WSPÓŁPRACA Z SYSTEMEM KONWERS 
2.1. Instrukcje 

Instrukoje systemu KONWERS podzielone są na dwie grupy: 
menażerskie i użytkowe. 

Menażerowi wolno podawać instrukoje z obu grup, natomiast 
użytkownikowi instrukcje menażerskie są niedostępne. Do 
instrukcji tych należą: LISTA, PODPIS, TAJNE, JAWNE, UTAJWI aM ' 
UJAWNIAM, ILOŚĆ, T. PYTAŃ, T. ODPOWIEDZI, ZMIANA, DOZWÓL, 
SAPI, RAPORT, CZAS, KONIEC* Instrukcjami użytkowymi są: 
PORCJA, KOLEJNA, WSTECZNA, POCZĄTEK, SKACZ, COFAJ, MERITUM, 
POWTÓRZ, TEKST, SŁOWNIK, PRZERWA, ILOŚĆ, DOŁĄCZ, DRUKUJ, KO¬ 
NIEC. System KONWERS dopuszoza możliwość skrócenia nazwy do 
pierwszych czterech znaków. Instrukoje wolno podawać tylko P° 
otrzymaniu od systemu specjalnego komunikatu (p. 2.4.4, P* 9)' 
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2.2. Podpis kodowy 

Podpis kodowy, czyli informacja identyfikująca użytkowni¬ 
ka, stanowi ciąg oztereoh znaków wybranyoh spośród liter i 
cyfr i zaczyna się literą. 

Użytkownik zgłasza menażerowi swój,tajny dla innych użyt¬ 
kowników, podpis kodowy oraz numer monitora, przy którym bę¬ 
dzie pracował. 

Menażer przekazuje te informaoje na listę systemową, a użyt¬ 
kownik, w konwersacji wstępnej z systemem KONWERS (p. 2.4.1) 
zobowiązany jest podać je jeszcze raz. 


2.3. Praca konserwatora systemu KONWERS 

Menażer ma możliwość współpracy z systemem w czterech se¬ 
ansach, dla których przyjęto następujące nazwy: konwersacja 
wstępna, seans pierwotny, seans wtórny i seans użytkowy. 

• ‘Konwersacja wstępna 

W tym seansie menażer przedstawia się systemowi KONWERS; 
następnie, jeśli trzeba, wozytuje z czytnika kart pełny zbiór 
óanych. i wreszcie określa w jakich, seansach, ohoe jeszcze pra¬ 
cować . 

• Seans pierwotny 

Menażer podaje tu tylko jedną instrukoję menażerską (LISTA), 
która spowoduje utworzenie w pamięci systemu tablicy użytkow¬ 
ników uprawnionych do współpracy z systemem KOMERS. Następ¬ 
nie może przejść do podawania instrukcji użytkowych bądź za- 
końozyć seans instrukoją KONIEC. 

• Seans wtórny 

Seans rozpoczyna instrukoją LISTA, której parametrem jest 
podpis kodowy menażera. Następnie menażer podaje inne instruk¬ 
cje menażerskie w zależności od potrzeb, a potem ewentualnie 
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instrukcje użytkowe. Instrukcja KONIEC, zamykająca seans wtór¬ 
ny, powoduje m.in. przesłanie utworzonych przez menażera ta- 
blio do pamięoi pomooniczej. 

• Pozostałe instrukcje menażerskie 
PODPIS - zmienia podpis kodowy menażera 

TAJNE 1 utajnia (ujawnia) odpowiedzi na określone pytani® 

JAWNE j dla jednej lub kilku komórek organizacyjnych 

UTAJNIAM] utajnia (ujawnia) odpowiedzi na określone pytani® 
UJAWNIAM J dla jednego lub kilku użytkowników 
ILOŚĆ - informuje zarówno menażera jak i użytkownika j®^ 

liczbą pytań dysponuje aktualnie system KONWERS* 
Menażer może tę liczbę zmniejszyć, a zatem może 
utajnić pytania o najwyższych numerach dla wszy st 
kich komórek organizacyjnych i dla wszystkich 
użytkowników 

T. PITAŃ - wykonuje jedną z wymienionych czynności: ujawni® 
odpowiedzi na pytania utajnione instrukcją 9 

aktualizuje teksty pytań, ujawnia i aktualizuj®• 
ujawnia i rozszerza zbiór tekstów pytań, ujawni®* 
aktualizuje i rozszerza ten zbiór 
T.ODPOWIEDŹ - rozszerza zbiór odpowiedzi na pytania lub afc tu 
alizuje cały ten zbiór z ewentualnym jego zwif^" 
szeniem 

- aktualizuje wybrane poroje odpowiedzi (zmieni® 
treść poroji, kasuje porcję lub dopisuje nową) 

- dopisuje do listy użytkowników uprawnionych do 

rzy stania z systemu KONWERS tylu nowych u żytko* 0 ” 
ków, na ilu pozwala miejsce w odpowiedniej ta 
systemowej 0 

- dołącza do systemu KONWERS systemy automatyo zn0h 
przetwarzania informacji 

- sporządza dokumentację praoy z systemem KONW^ 1 
określonego użytkownika w określonym dniu 

- sporządza bilans ozasu wykorzystanego przez d® 11 
użytkownika 

- kończy seanse pracy z systemem KONWERS 


ZMIANA 

DOZWÓL 

SAPI 

RAPORT 

CZAS 

KONIEC 
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2.4. Praoa użytkownika z systemem KONWERS 
2.4.1. Konwersaoja wstępna 

Po rozpoznaniu użytkownika system KOMERS sprawdza, ozy 
może podjąć z nim praoę, tzn. ozy posiada w swej pamięoi odpo¬ 
wiednie zbiory danych i ozy w tym samym czasie nie praouje 
menażer. Jeśli te warunki są spełnione, wówozas KOMERS prosi 
użytkownika o dokładną identyfikaoję, tzn. o jego podpis ko¬ 
dowy i numer monitora. Po podaniu tych informacji w sposób 
prawidłowy użytkownik może rozpooząć właściwy seans użytkowy, 
ożyli podawanie kolejnych instrukcji użytkowych. 


2.4.2. Seans użytkowy 

W tym seansie użytkownik może otrzymać wszystkie informa¬ 
cje jakimi dysponuje dla niego system KOMERS. W tym celu po¬ 
daje wybrane lub wszystkie instrukcje użytkowe. 


2 .4.J. Instrukcje użytkowe 


PORCJA 


KOLEJNA 

WSTECZNA 

POCZĄTEK 

SKACZ 

COFAJ 

MERITUM 

POWTÓRZ 

TEKST 

SŁOWNIK 

ILOŚĆ 

PRZERWA 


- rozpoczyna seans użytkowy, powoduje wyświetlenie 
na ekranie porcji odpowiedzi, której numer okreś¬ 
lają parametry instrukoji 

- wyświetla następną poroję odpowiedzi 

- wyświetla poprzednią poroję odpowiedzi 

- wyświetla pierwszą porcję z danego wariantu 

- wyświetla pierwszą porcję następnego wariantu 

- wyświetla pierwszą poroję poprzedniego wariantu 

- wyświetla pierwszą poroję trzeciego wariantu 
_ powtarza ostatnio wyświetloną odpowiedź 

- wyświetla tekst pytania, na które były udzielane 
odpowiod zi 

- wyświetla kolejne teksty pytań, poozynając i kon- 
oząo na żądanym przez użytkownika 

- informuje iloma pytaniami dysponuje KOMERS 

- przorywa na chwilę konwersację 
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DRUKUJ - informuje jakie systemy API są podłączone do sys¬ 
temu KONWERS 

DOŁĘCZ - wyświetla aktualne wyniki żądanego systemu API 

KONIEC - kończy seans użytkowy 

2.4.4. Teksty standardowe i diagnostyka błędów w konwersacji 
użytkownika z systemem KONWERS 

1) SYSTEM KONWERS PYTA KIM JESTEŚ — pierwszy komunikat od 
systemu. Odpowiedzią winno być słowo UŻYTKOWNIK lub tyl¬ 
ko U 

2) ODPOWIEDŹ NIEZNANA SYSTEMOWI — sygnał przy nieprawidłowej 
odpowiedzi użytkownika w konwersacji wstępnej 

3) SYSTEM KONWERS ZAJĘTY - POCZEKAJ - informaoja o tym, że 
aktualnie pracuje menażer 

4) BRAK DANYCH - ZWOLNIJ SYSTEM - w pamięci systemu KONWERS 
nie ma niezbędnych danych 

5) PROSZĘ ZŁOŻYĆ PODPIS 

6) PODAJ NUMER SWEGO MONITORA 

7) NIEPRAWIDŁOWY PODPIS - system KONWERS pozwala użytkowni¬ 
kowi na czterokrotne poprawienie pomyłki w podpisie. Pi4" 
ta omyłka eliminuje użytkownika z pracy z systemem 

(p.p. 18) 

8) PODAJ TERAZ INSTRUKCJĘ PORCJA - system KONWERS przypomina 
użytkownikowi, że tą instrukoją musi zacząć seans użytko¬ 
wy 

9) PODAJ NASTĘPNĄ INSTRUKCJĘ - informaoja, że system KONWERS 
jest gotowy do przyjęoia i realizacji kolejnej instrukoji 
użytkownika 

10) NIEPRAWIDŁOWE POLECENIE - błędnie podana nazwa instrukoji 

11) NIEPRAWIDŁOWA WARTOŚĆ - błędnie podany parametr instruk¬ 
cji 

12) KONWERS NIE PRZYJMIE ZLECENIA - zleoeniem była instruk- 
cja menażerska 

13) INFORMACJA NIEDOSTĘPNA - pytanie, na które użytkownik 
oczekuje odpowiedzi zostało utajnione 
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14) BRAK DANYCH W BANKU SYSTEMU - luka w zbiorze odpowiedzi 

15) PYTANIE NIE ISTNIEJE - żądanego numeru pytania nie ma 
w zbiorze pytań 

16) KONWERS ZAWIERA ... PYTAŃ - informacja o liczbie pytań 
jaką dysponuje KONWERS 

17) SYSTEM NIE DOŁĄCZONY DO KONWERS - żądany przez użytkow¬ 
nika system API nie jest jeszoze podłąozony do systemu 
KONWERS 

18) MUSISZ SKOŃCZYĆ PRACĘ - usunięoie przez system KONWERS 
użytkownika nieupoważnionego do współpraoy 

19) ZWOLNIŁEŚ MONITOR - DZIĘKUJEMY - prawidłowe zakońozenie 
seansu użytkowego 


3. ZAKOŃCZENIE 

Zadanie systemu KONWERS polega na wizualnym udostępnieniu, 
w odpowiednio krótkim czasie, żądanych zbiorów danych na mo¬ 
nitorach ekranowych zainstalowanyoń w wybranych komórkaoh 
organizacyjny ch. 

Wiele szczegółów nie zostało jeszcze dopracowanych ze wzglę¬ 
du na brak wyposażenia technicznego i dokumentacji zarówno 
sprzętu jak i firmowego oprogramowania. 

System KONWERS zapewnia poufność i jest w miarę łatwy w ob¬ 
słudze, jest też dostatecznie elastyozny pozwalająo na dość 
szeroką wymianę informacji zdezaktualizowanej na świeższą, na 
rozszerzenie listy pytań i odpowiedzi oraz zbioru użytkowni¬ 
ków . 

System KONWERS spełnia zadanie zautomatyzowanej służby in¬ 
formacyjnej dla kierownictwa resortu od strony organizacji 
wizualnej prezentacji zamawianych informacji ułatwiających 
podjęcie optymalnej decyzji. 
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CMCTEMA C PA3AEJIEHEEM BPEMEHM MH<K)PMMPOBAHMH pyKOBOflCTBA 
BEflOMCTBA 

Pe3MMe 


CucTeMa KONTTSRS npencTaBJiaeT codoft CHCTeMy 3 KpaHHoro H3»- 
dpaseraw npnroTOBJieHHUx nopimti HH$opMamaH. Jim npHBeneHHfl 
chctsmu b neiicTBHe nojiB30BaTejiB nepejiaeT HfleHTH$Hmipyiomy» 
ero HH$opMamno. B tot momcht , Korna kony/ers TpaHCjnipyeT cur- 

HHJI TOTOBHOCTH K B3aHMOHeJłCTBHB, n0JIB30BaTejIB HaaHHaeT ne- 
penany npHKJia,nHHx HHCTpyKiuiii. B nawiHTH cucTeMH HaxonnTca H0 
donee 12 tbicot nopmift HH$opMamra, npnneM Kajman conepMT h« 
dojiee 1040 3HaK0B. Ilopmiii odBejmiunoTCfl no Tpn b TaK Ha 3 biBa- 
eMue BapnaHTU, a BapnaHTbi no HeTBipe - b dojiBimie arperauns 
Ha3HBaeMne oTBeTaMH Ha Bonpoca. IIojiB30BaTejiB CHCTewm kony/EBS 
(popMyjmpya Bonpoc, yKaairoaeT HOMep OTBeTa, Howep BapnaHTfl 
u HOMep nopnjm. Ecjih OKaaceTcn, hto naHHŁiił nojiB30BaTejiB ynoft' 
HOMoneH k nojiyaerano yKa3aHHofi hm nopujiH HH^opMaujni, 3Ta hh- 
$opMauęnH dyneT nponeMOHCTpnpoBaHa Ha sKpaHHOM MOHHTope. B 
onpenejieHHoił enHHHiie BpeMeHH CHCTeMoft KONWERS MoaeT noJiBSO- 
BaTBCH 14 nojiB30BaTejieii H3 10 opraHH3aujiOHHLix emiHHii, b tom 
HHCJ ie jyin Karoofi dyneT npejmasHaneH onpenejieHHHfl mohhtop. 
KpoMe nojiB 30 BaTe;ieił, chctsmoS kcny/ers nojiB3yeTcn Taiose "Me- 
Haacep", T.e. jihup ynojiHOMoneHHoe KOHCTpynpoBaTB, o<3hobjihtb 
CHCT eMy h ocymecTBJWTB 3a Heii yxon. MeHsueep BunojuweT cboio 
3anany b MeHaxepcKnx ceaHcax, nepenaBan HHCTpyKmm, Henoc- 
TynHHe jpyraM nojiB 30 BaTejiHM cucTeMH konwers . CncTeMa KON- 
WERS HCnOJIHHST pOJlB 8BT0MaTH3Itp0BaHH0ii HH$OpMaUHOHHOit OJiy®" 
du jyiH pyKOBOUCTBa BeHOMCTBa B OTHOOieHHH OpraHH3amM BH3y- 
ajiBHoro H30ÓpaaeHHH 3aKa3HBaeM0ft HH$opMamiH, oÓJierHaEiueit 
CpHHHTH© OnTHMaJIBHOrO pemeHHH. 
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A MULTIACCESS SYSTEM OF INFORMING MINISTRY MANAGEMENT STAFF 


Summary 

The KONWERS system ls a multiaccess display system for displaying 
prearranged portions of Information. To initiate the system, the user 
should key up his identification codę. As soon as KONWERS conveys the 
signal announcing its readiness to operation, the user can start to key 
up his successiye appropriate instructions. The memory of the system 
contains up to 12 thousand portions of Information, each having capacity 
not exceeding 1040 characters. The portions are grouped in threes in the 
so-called variants, and the yariants themselyes in fours in greater sets 
called the answers to the ąuestions. Upon formulating a ąuestion, the 
User indicates answer number, yariant number and portion number, If it 
is revealed that a giyen user is authorizod to receiye the reąuested 
portion of Information, it will be displayed. In a giyen time unit, 
KONWERS can be accessed by 14 users from 10 departments, to each of which 
a terminal is assigned, Additionally KONWERS is used by the "Manager", 
i.e. a specialist authorized to install, maintain and update the system, 
The Manager works during so-called manager sessions and issues commands 
not ayailable to other users, KONWERS meets the reąuirements of the 
automated Information seryice for the ministry managerial staff with re- 
gard to organization of yisual presentation of Information wanted for 
facilitating the optimal decision making. 


© Instytut Maszyn Matematycznych 
q 2-Q78 Warszawa, ul. Krzywickiego >4 




Lista uczestników sympozjum 


1. W. Babczenko 

Okręgowe Laboratorium Poczty i Telekomunika¬ 
cji. Warszawa 

2. W. Bajurski 

Instytut Łączności, Warszawa 

3- A. Barczak 

Akademia Sztabu Generalnego, Warszawa 

4. R. Bednarz 

Instytut Badań Jądrowych Cyfronet, Warszawa 

5. T. Berkan 

Wydział Elektroniki Politechniki Warszawskiej, 
Instytut Maszyn Matematycznych, Warszawa 

6. J. Białasiewicz 

Przemysłowy Instytut Automatyki i Pomiarów, 
Warszawa 

7. P. Bielkowicz 

Instytut Maszyn Matematycznych, Warszawa 

8. J # Bromirski 

Instytut Cybernetyki Technicznej Politechniki 
Wrocławskiej, Wrocław 

9. W # Bytnerowicz 

Zakład Doświadczalny Oprogramowania przy Insty¬ 
tucie Maszyn Matematycznych, Warszawa 

10. J. Chamski 

• 

Instytut Łączności, Warszawa 

11. R. Chełstowski 

Instytut Automatyzacji Systemów Zarządzania t 
Wojskowej Akademii Technicznej, Warszawa 

12. J. Chmurzyóski 

Wydział Cybernetyki Wojskowe., .k-demii Tech-/ 
nicznej, Warszawa 

13. S. Choromański 

Instytut Maszyn Matematycznych, Warszawa 

14. S. Chrobot 

Wydział Cybernetyki Wojskowej A' idemii Tech¬ 
nicznej , Warszawa 

15. T. Czachórski 

Zakład Systemów Automatyzacji Kompleksowej 

PAN, Gliwice 

16. J. Czajkowski 

Krajowe Biuro Informatyki, Warszawa 

17. E. Demczyszyn 

Instytut Maszyn Matematycznych - Oddział 
śląski, Katowice 

18. A. Dernałowicz 

Zakład Doświadczalny Minikomputerów przy Insty' 
tucie Maszyn Matematycznych, Warszawa 

19. J. Dudziak 

Instytut Cybernetyki Technicznej Politechniki 
Wrocławskiej, Wrocław 

20. T. Englert 

Instytut Maszyn Matematycznych, Warszawa 

2*1. R. Faber 

Politechnika Warszawska, Warszawa 
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22. Z. Fryźlewicz 

Instytut Cybernetyki Technicznej Poli¬ 
techniki Wrocławskiej, Wrocław 

23. A. Gecow 

Instytut Badan Jądrowych Cyfronet, Warsza¬ 
wa 

24. J. Grzywacz 

Instytut Automatyzacji Systemów Zarządza' 
nia Wojskowej Akademii Technicznej, War¬ 
szawa 

25. A. Hildebrandt 

Instytut Łączności, Warszawa 

26. E. Hudyma 

Instytut Cybernetyki Technicznej Politecb- 
niki Wrocławskiej , Wrocław 

27. Z. Huzar 

Instytut Cybernetyki Technicznej Politech¬ 
niki Wrocławskiej, Wrocław 

28. E. HHbner-Biegalska 

Instytut Maszyn Matematycznych, Warszawa 

29. B. Janicka 

Instytut Automatyki Przemysłowej Politech¬ 
niki Warszawskiej, Warszawa 

30. L. Jung 

Wydział Cybernetyki Wojskowej Akademii 
Technicznej, V!arszawa 

31. J. Karczewski 

Centrum Obliczeniowe Polskiej Akademii 
Nauk, Warszawa 

32. S. Karkowski 

Instytut Techniczny Wojsk Lotniczych Ze 0- 
pół III, Warszawa 

33. J. Kasprzyk 

Instytut Maszyn Matematycznych, Warszawa 

34. K. Koleśnik 

Instytut Cybernetyki Technicznej Politech 
niki Wrocławskiej, Wrocław 

35. W. Komorowski 

Instytut Cybernetyki Technicznej Polit® c ^ 
niki Wrocławskiej, Wrocław 

36. E. Kosmulska 

Instytut Cybernetyki Technicznej Polit 0ch 
niki Wrocławskiej, Wrocław 

37. Z. Kosowski 

Zakład Doświadczalny Oprogramowania P** 2 ? 
Instytucie Maszyn Matematycznych, Warsz 

38. K. Kowalski 

Instytut Cybernetyki Technicznej Polit 0cb 
niki Wrocławskiej, Wrocław 

39. J. Kozłowski 

Instytut Automatyzacji Systemów Zarzą dz ® 
nia Wojskowej Akademii Technicznej, War ~ 
szawa 

40. R. Krasnodębski 

Instytut Ochrony Środowiska, Oddział we 
Wrocławiu 
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4l. P. Kremienowski 

Ośrodek Badawczo-Rozwojowy Maszyn Cyfro¬ 
wych M ELWRO n , Wrocław 

42. Z. Kujda 

Instytut Maszyn Matematycznych, Warszawa 

43. J. Kuśnierz 

Instytut Dowodzenia Akademii Sztabu Gene¬ 
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